A common security theme in corporate America is to secure the outside Internet from the safe intranet. As a penetration tester, I’ll tell you that if you have over 1000 employees there is no “outside”.

Firewalls, NAT devices, and anti-exploitation techniques have made traditional remote exploitation extremely difficult. Pure remote exploitation over a technology such as RPC, IIS, etc still occurs but it’s much less common. Instead, attackers have transitioned to user driven attacks such as phishing, malicious emails, malicious websites, or malicious documents. The basic idea is to get your users to exploit their box for the attacker. Once the user does something unwise, the workstation inside your network is owned. If you have 1000+ workstations, there is virtually no chance that one of your employees won’t eventually enable this type of attack. When you factor in USB sticks, Wifi, VPN access, and laptops that travel, no reasonably large network can assume the internal network doesn’t touch the Internet.

Now that we’ve established the Internet can get into your internal hosts, can it get out?

Brad Antoniewicz’s recent blog describes several data exfiltration techniques. I’ve had success with DNS tunneling. Almost every firewall allows outbound DNS queries and the technology is well proven. Once your local workstation has been exploited, DNS tunneling will let the data out. However, my favorite technique is simple HTTP. First, outbound HTTP access is almost as universal as outbound DNS. To me, there are several benefits of HTTP traffic over DNS Tunnels:

1. DNS tunneling is innately anomalous – the messages are larger and more frequent than normal. Similarly, you’re likely ignoring TTL values. All of these can be red flags

2. Programming an HTTP tunnel is simple. You setup a fake page, setup a trigger value for data, post/get data as needed. You simply need to use the straightforward MS InternetOpen() and similar functions.

3. Many hosts now have firewalls that prompt to allow outbound access by application. In general, it’s best to use DLL injection to hook your callback into IE to get its access and to use any proxy authentication that may be needed. This technique almost always lets me out to the Internet from a workstation.

In various penetration tests, I’ve successfully used remote access tools that utilize HTTP traffic by hooking IE. It’s been VERY effective. Do you have technology to prevent this type of remote command and control?

In closing, as you design your network security policies and deploy technologies dependent on being safe from within, I encourage you to think of both how threats get into your network and how they can get out. If an attacker can do those two things, depending on your perimeter, this is asking for a security incident.