Scratching The Surface of Advanced Threat “Protection”: Part 1

WTF is it? Ahhh… just throw it in the sandbox

It has been quite a while since I’ve last posted, but I am going to try and make a go of it and be a little more active on here.

The aim of this post is to provide you with an overview of Advanced Threat Protection / Prevention, which seem to be all the rage these days in the security product market. Over the past several months, I’ve had the pleasure of encountering these products on several engagements and even had the opportunity to work with some awesome security engineers who have and were in the process of testing / implementing this technology. This post will serve as an introduction to Advanced Threat Prevention and will be the basis for subsequent posts that will cover: ATP Evasion For Penetration Testers (Part 2), Testing ATP Products (Part 3), ATP Network Implementation and Placement (Part 4).

It was quite difficult to come up with a title for this post, because each vendor has their own nomenclature for (essentially) the same technology, but generally “Advanced Threat Protection” or ATP seems to be accepted across the board. However, “Prevention” is more appropriate being that ATP is a preventative control. Marketing… ehh

What is ATP and how does it work?

Advanced Threat Prevention is a security control that uses a two-fold approach to stop malware from entering into and / or propagating across a network.

First Line of Defense

Uses signature-based detection to block known threats. I think it is safe to say that we all know the efficacy of signature-based detection, and that it isn’t all that. Signature-based detection is only as good the latest update, and offers weaker protection against polymorphic and metamorphic viruses. Additionally, ATP product vendors obtain these signatures from other vendors that actually develop antivirus software. The better the AV vendor is at identifying new malware and the frequency that they update their definitions all factor into how well this first line of defense will work. Not to mention… there are many evasive measures out there to subvert this type of detection. Enter the unknown…

Second Line of Defense

If the file bypasses signature-based detection, it’s sandboxed. In case you are unfamiliar with sandboxing, all it boils down to is emulating the operating system (with ATP each product typically has several different sandbox profiles, each with a different version of Windows [mostly] [note that] with various service packs installed) on a virtual machine, executing the unknown file, and observing changes to and behavior of the VM after the file has been executed. This activity would include new processes, changes to the file system, registry changes, connection attempts, etc.

Sand EVERYWHERE!

Let’s dig a little deeper. These products (from what I’ve seen) have three different sandbox implementations, which are all pretty straightforward.

  • Physical Appliance + Local Sandbox: The sandbox is on the appliance itself, which would require it to push more ponies than the other two implementations. Hence… the price tag goes up and the performance is usually a bit slower.
  • Physical Appliance + Cloud Sandbox: It only makes sense that we harness cloud power here. When an unknown file is detected it is then uploaded to the cloud to be processed. As usual, the cloud always comes with a price. In this case, a subscription (typically based on an upload quota). To see the results of the analysis, you also have to login to a separate system on the web. Not the end of the world.
  • Cloud Proxy + Cloud Sandbox (Derf!): Exactly as it sounds. Now this scales the best out of all three, because all you have to do is direct your network traffic through a proxy, but some of us out there might not feel 100% comfortable with that idea. The other downside is that this approach won’t detect threats within the network.

General ATP misfires…

Every control has its pros and cons. Advanced Threat Prevention is no different. These are some of the limitations that I have noticed:

  • Remember above when I mentioned, “each product typically has several different sandbox profiles, each with a different version of Windows”? Well that’s just it. The sandboxes that I’ve seen (for the most aprt) only emulate Windows. Now I know that Windows makes up the lion-share of the productive work place, but BYOD is changing that dynamic, especially with smart phones. If signature-based detection misses the file, and it cannot be run within the sandbox, then it most likely will make its way onto your network. Some vendors have recently announced that they now support Android and Mac OS X, most notably FireEye and Palo Alto Networks (This is not an endorsement!).
  • Some of the products use the “sacrificial lamb” approach. What this means is that if a file makes it passed signature-based detection, the file is then allowed ingress. However, a copy of the file is sent to the sandbox for analysis. If the verdict of the analysis is malicious, in most cases ATP will block the file on subsequent attempts to download it. At that point it is up to your endpoint protection =(
  • Finally, there are file type limitations. Executables, binaries, dll’s, PDF’s, Office documents, zip files are all expected, but for some odd reason plenty of malicious Office documents tend to make their way through. Also, not all vendors analyze jar, rar, gz, apk’s, and fla’s 😉 – See where this is going?

Wrapping it up…

So, I do want to reiterate that this is just an intro to what ATP is and how it works. Not too deep of a dive, but enough to get us ready for what comes next. In the next post, I am going to discuss my experience with ATP and some of the ways that I have dealt with working around Advanced Threat Prevention from a penetration tester’s perspective.

Leave a comment

Leave A Reply