In my last post, “Scratching the Surface of Advanced Threat Protection”, I covered what ATP actually is and how it works. In this post, I am going to provide you with a basic methodology that will assist in evading Advanced Threat Prevention in the event you happen to encounter it during a penetration test. The second part of this methodology will also prove useful for testing these products on their own, prior to network implementation, which will actually be the third part of my ATP series (Testing Advanced Threat Protection Products).
A good penetration tester knows the importance of performing thorough reconnaissance. The more information you gather about your target of evaluation, the better your chances are of having a successful penetration test. When we learn that Advanced Threat Prevention may be a game changer, there are some additional steps to take to increase your odds.
It all boils down to your OSINT skills. Defeating ATP isn’t necessarily any more technical than antivirus evasion. It just requires you to do a little more R&D. A good friend once told me, “if you fail to plan, you plan to fail” – Since then I’ve adopted this saying as my personal mantra.
Let’s start at the top and work our way down.
Tactics without strategy is the noise before defeat – Sun Tzu
If your target is large (chances are that they are if they can afford some of these products) job postings are an excellent way to determine if ATP is in play, and what products they may actually be using. These are the questions that you want to answer:
If they mention specific vendors you’ve got a head start. If they mention versions, then you’re already coming out ahead. Some ATP vendors actually have product specific certifications. If the posting lists any of these certifications as a qualification that may be a good indication as to what products your target is using in their environment.
(This is a screenshot of a job posting on Dice.com. The description clearly mentions, “Advanced Threat Protection”, and at the very bottom it lists “Specific Technologies”. If you’ve done your homework, you’d know that SourceFire, FireEye, and McAfee all have ATP products on the market.)
As your recon progresses, you may use social media to determine who the players are (IT + Security staff). Digging a little deeper into the activities of these individuals may lead you to discussions and/or posts requesting help or more information about ATP products. I’ve found that it’s not always the best avenue, but if you are thorough, it would be foolish not to investigate. LinkedIn Groups seem to be a good starting place.
If you can reliably determine which product is in use then this is the most crucial part of the process. Learning the product is undoubtedly the key to defeating it. These are the questions you want to try and answer during your recon:
What AV vendor signatures are in use?
In part one of my ATP series, I mentioned that ATP products use signature-based detection as their first line of defense. The product vendors themselves usually partner with antivirus vendors to obtain these signatures. If you can determine which AV vendor(s) are being used, then you can (at the very least) increase your chances of defeating signature-based detection.
Depending on the product this can be much harder than anticipated as ATP vendors want to keep their intellectual property confidential, but that doesn’t mean that you cant use the process of elimination 😉
I’ve found success by searching for acquisitions of AV vendors by ATP product vendors or partnerships between the two.
Can you get any background or context on the sandbox technology?
You are not going to get too deep of detail on the actual sandbox technology being used, but you can learn its limitations. The two main things that you want to identify are the following:
ATP vendors sell these products for a lot of money so they aren’t about to tell you what they DON’T support. Instead, they will boast about what they do support.
(This screenshot was taken from the WildFire Datasheet. Hmm…. Looks like WildFire doesn’t emulate Windows 8 or OS X.)
Strategy without tactics is the slowest route to victory – Sun Tzu
There is a plethora of information out there about how to defeat anti-virus signatures and the intent of this post is not to be a tutorial on signature-based AV evasion, but I will run down some of the basics.
Signature-based detection is fairly straightforward. It can only identify what is KNOWN. Antivirus vendors scan the contents of a file and make the determination of whether or not those contents are malicious (pre-signature). If the contents of that file are determined to be malicious, a signature is created and added to the vendor’s database (definitions). When the product scans a file it compares the content of that file to signatures within its database. If a signature is detected, then that file is malicious. It is (literally) a race for the vendor to quickly identify malware, create a signature, and update the product. Antivirus evasion is essentially reaching the finish line first by creating a file with contents that are unknown… hence no signature.
Once you know which AV signatures are in play, you’ve already made substantial progress. Now comes the tedious effort of bypassing or “evading” the product. There are several common techniques out there, and here is the basic process:
Step 1 is self-explanatory. Step 2 is where you need to be creative. Metasploit has several tools available for encoding your payload. Msfvenom is my personal favorite, but some people are old fashioned and still use msfencode (It doesn’t matter which route you go, but msfvenom will definitely save you a step or two). Msfvenom has a multitude of available encoders and most commonly used for this process is x86/shikata_ga_nai.
Encoding works, because some products just can’t handle the file, but this isn’t always the best route. Alternatively, you could use a tool such as Hyperion, which will encrypt the payload so that AV cannot extract a valid signature, and then decrypt itself by brute forcing the file’s symmetric key. Using a combination of encoding and encrypting will definitely improve your chances, but may still not provide you with the desired result.
If you’ve read any good write-up on antivirus evasion the author will often mention that you are better off writing your own executable. This definitely holds true. AV products will sometimes disregard encrypted files and automatically consider them malicious, and they’ve also become more wise about encoding by not only looking for the payload, but by creating a signature for the encoded payload as well. Writing your own executable creates an entirely unknown file.
I highly suggest you do some research and try each technique. There are also some great tools out there. Veil Evasion Framework is phenomenal and automates the process. Originally released at Shmoocon last year by Chris Truncer, Mike Wright, and HarmJ0y. Chris Truncer’s blog is also an excellent resource.
Step 3 is exactly what it sounds like. Armed with the information that you have gathered from your OSINT, test your file against the product that uses the same signatures as the ATP product you are trying to circumvent. Note: Do NOT rely on VirusTotal.com! and… test on a machine or in a VM that is not connected to the internet. This should prevent the file from being submitted to the vendor.
Step 4… need I explain? The whole process may seem easy, but it can be tedious and it can take some time before achieving the result that you need. Be patient and do research.
Let’s assume that we have been successful at defeating signature-based detection. Now we are on to the dynamic analysis that takes place in the sandbox where the file is actually going to be executed and monitored in several different environments. Rather than tutorialize, I am just going to give you an overview as to what can be done to work around the sandbox.
If we did a good job determining what file types the ATP product supports and what system profiles it virtualizes, we can deduce which ones are NOT supported. Right off the bat you know that you are going to deliver your payload in an unsupported file type. If you know that your target network has a decent number of OS X users, why not target them?
You must understand that the sandbox is behavioral. It evaluates an unknown file and looks for signs of suspicious / malicious activity. Typically, it is going to look for these 5 things:
The products (most of them) try to be as efficient as possible, so the sandbox does have TTL. You can exploit the time-to-live by letting your code sleep or by implementing a series of dummy loops to wait it out. While doing some research on AV evasion, I actually found this tidbit out from a post on StackExchange and it worked like a charm.
while True: time.sleep(payloadDelay) ## #Do bad things ## except: pass ... #Side note: I noticed (roughly) a 20% increase in success by increasing the delay from 10 minutes to 15.
I feel like I can go on forever about this topic, but the reality of it is that you need to experiment on your own. Antivirus evasion is a big component, so I highly suggest that you do some research there. I haven’t (yet) tried it myself, but Cuckoo Sandbox may be a good way to test out your code. At the end of the day you need to learn your enemy’s moves. In this case, your enemy is whichever ATP product your find yourself coming up against.
In my next post (Testing Advanced Threat Prevention Products) I am going to discuss testing ATP products in your lab environment prior to integrating them into your network.