The security landscape is always changing. Both attackers and defenders are constantly facing new challenges. The content of the pentester’s toolbox today is very different from just a few short years ago, as has the array of technologies, network administrators, and security practitioners have at this disposal to defend against increasingly capable threat agents. With that out of the way, sometimes there is value in looking back. I have been reflecting on some of my recent experiences attempting to escalate privileges on contemporary Windows platforms. The conclusion I have come to is: I frequently cannot. Having a meterpreter shell with some unprivileged service account on Server 2008, 2012 or Windows 8.x in no way guarantees I am going to get anywhere with a simple “getsystem” - far from it, in fact. Happily, I am probably not even that lucky from the outside, often the best I am going to get is some klutzy web shell. So I am left with choices: I can pour a bunch of effort and risk of detection into gaining greater access to the webserver, or I could just move on. I like that latter option because let’s face it - all the goods are in the backend database or otherwise on your internal network; your front end webhost is boring. In the previous millennium before NATs were everywhere, there was a useful bit of software called a socks proxy, or sockets proxy. Host A would contact Host B asking to connect to Host C on a network that B could reach but A could not, usually because B was dual homed; B would relay transport layer messages for A and C. This was and is in more recent forms like SSH a good method for firewall bypass.  Most of the time though firewalls, software or otherwise, they won’t let traffic through to the listening port form the outside, and your HIPS software is going to freak when it sees something new listening anyway. Actually, SSH’s own dynamic port forwarding can do this, but since Windows servers don’t usually run SSH, I would need to authenticate with daemon sshd which probably isn’t configured to allow port forwarding if it is there. If I try to deploy my own SSH client or daemon, various software restriction controls are likely to block any common binaries. What I need to do to solve this is to split my proxy into a few parts: the service proxy, a connection broker, and a library I can dynamically link. The library will wrap calls to connect(), getaddrinfo(), gethostinfo(), gethostbyname(), and a few others so I can run my favorite tools through it. That will be enough to give me basic DNS and TCP on your network while satisfying a few conditions.

• The service proxy need only make a single outbound sockets connections to me the attacker
• The connection can be made on arbitrary port
• The payload is small (13K and should be easily reduced from there) and can possibly be loaded without hitting disk, through reflective injection via Powershell or Windows Scripting Host to evade application policies if needed.
• No elevated privileges should be required
• It needs to support a number of simultaneous connections so more complex software like web browsers can be supported.

It all works as follows: The service proxy payload is delivered to the victim. It creates an outbound sockets connection to the broker. Client programs are loaded with library wrapper. When a client attempts to open a socket or perform a DNS lookup, a message is routed instead to the broker which forwards the request to the proxy via the existing socket. The proxy performs the function using the local resource such as DNS resolution on the victim and replies to the broker. The broker finally passes responses back to the client. In the case of a new socket connection, a forwarding relation is established in the broker and the proxy to continue passing messages and socket events like close() for the life of the client connection. A hypothetical situation:  We have a file upload vulnerability on a webserver, and have uploaded a basic webshell, which we can use, fetch and execute the service proxy payload. The server can make outbound connections on port 443. The attacker is at 172.16.235.140. First, we setup a few environment variables on the attacking computer, which the broker and library wrapper will use: Then we will make the broker component ready: The payload is executed on the victim: In this case, the victim machine is on TrustedSec’s internal network. As the attacker, I don’t know much about the internal network but fortunately because my proxy offers me DNS resolution using the victims resolver, I will guess that there is an “intranet.companyname.local”. Great! Looks like an IIS server there, which is a place to start anyway. Maybe I’ll start iceweasel with the wrapper and explore that for a while! Right now, my proxy only handles sockets API level TCP and basic DNS functions. Some of the would be “goto” tools like nmap don’t function completely as they require raw sockets and other lower level access. Still, using this technique I have a way to comfortably explore a DMZ with only a partial compromise of a front end server; maybe I’ll be really lucky and discover you have NAT’d a host all the way inside to your core network. Even without nmap I can enumerate live hosts and port scan with other techniques such as:

for I in $( seq 1 254 ); do LD_PRELOAD=./proxify.o nc -z -v 10.10.10.$I 445 &  done

and

nc –v –z 10.10.10.10 20-512

Here is another thought for you: The victim was a virtual machine that shared a gateway with the attacker, not a requirement in the compromised web host example but not uncommon in a coffee shop or hotel. TrustedSec’s VPN does not allow split tunnel traffic that is all traffic on the client is sent into the VPN, except the VPN traffic itself of course. Like most VPN clients, it accomplishes that by replacing the route to the gateway with a host route via the gateway for the VPN pier, and changing the default gateway to the VPN pier’s inside address. Consequently, non-tunneled connections can still be made to the gateway’s address directly. Considering the pwnd gateway scenario, an attacker might use tools like site cloner in the SET Toolkit to compromise an endpoint, especially if he can redirect HTTP or DNS traffic. After compromising the endpoint and injecting the service proxy payload the attacker simply waits for the victim to connect to their VPN and voila! The service proxy can still call the attacker back at the gateway IP and every connection it proxies will route via the VPN! If your endpoint security and client firewall configurations are not up to task, your datacenter might be a lot less isolated from everyone else at the coffee shop than you guessed. Do you know who is really on your VPN? Want to know more? Want to see some source code? Come out to DefCon where TrustedSec will be presenting this and more! Details to follow! This article was written by Geoff Walton of TrustedSec