Inside the Cloud Sandbox: How Capture Advanced Threat Protection (ATP) Works
Last year, SonicWall discovered and created protections for more than 56 million new forms of malware. Because it takes time to create and roll out hundreds of thousands of protections each day, something must be done to discover and stop unknown malware, namely zero-day attacks.
The answer is Capture Advanced Threat Protection (ATP), a cloud sandbox and a core part of the SonicWall Capture Cloud Platform. In order to stop new cyberattacks, this isolated environment — independent from your network — runs suspicious files to understand their objectives.
Because of its effectiveness, SonicWall makes it available on our firewalls, email security solutions, Secure Mobile Access (SMA) and Capture Client Advanced endpoint protection solutions. Each of these use Capture ATP in different ways:
- For firewalls: In the case of the firewall, a broad range of file types are sent over if they are greylisted, which means 1) they have not been convicted by Gateway Antivirus (blacklisted) and 2) were not previously seen by the firewall in question (whitelisted).
- For email security: Similarly, email security will automatically send unknown files arriving via email to Capture ATP for analysis before sending them along to inboxes.
- For mobile access: If someone tries to upload a file to a shared drive (a common malicious attack vector), SMA will test the file to ensure it is clean before being accessible by others in the organization.
- For endpoint protection: Last, Capture Client is an antivirus solution that continuously monitors the behavior of a system. Since it is common for malware to utilize evasion techniques (such as timing delays), sending suspicious files to Capture ATP is an intelligent way of eliminating malware before it executes.
Now that we have covered a bit of context, we’ll now explain how it works once one of these solution sets has either automatically sent a suspicious file to Capture ATP or an administrator has manually submitted a file for analysis.
Step One: Verdict Check
At the time of writing, the Capture ATP sandbox service receives over 1.5 million requests to test suspicious files each business day.
The first stop for these files is a verdict check. SonicWall summarizes each file (sent via encryption) it sees as a hash and retains a verdict for that hash indefinitely and does not save your files. By keeping a verdict for each hash (for each file), we are able to quickly send a conviction or acquittal back to the submitting solution or administrator within milliseconds. Of the millions of submissions SonicWall sees each week, only around 45 percent are unique, so this step is vital.
Step Two: Community Check
If we have never seen a file before it doesn’t mean someone else hasn’t. We check for convictions for the file’s hash against a pool of over 60 virus scanners to see if they found this file to be malicious.
Note: SonicWall doesn’t send your files to anyone for analysis.
Step Three: Dynamic Processing
If we haven’t seen it before (verdict check) and no one else has seen it before (community check), we run it through multiple engines simultaneously. This is where the fun begins, because we can do so many unique things with the code that a firewall or an endpoint can’t, such as fast-forward it to look for timing delays or break it apart in memory and examine the sequences.
Capture ATP was designed to be a multi-engine environment because of the common use of evasion tactics used in malware. Academically, the concept of a sandbox is easy to grasp, but once you understand their inner workings you can design code to slip past what they check for or not activate if you sense that the code is not on a normal system.
Getting past one sandbox is moderately difficult. Evading multiple engines, which in turn have multiple ways to find malware, should be nearly impossible.
In order to find the most evasive malware, Capture ATP runs code with hypervisor-level analysis, full-system emulation, virtualization and with SonicWall’s patent-pending Real-Time Deep Memory Inspection (RTDMITM). This is done to see what code wants to do from the application, to the OS, and down to the firmware.
In an ideal world, every piece of malware we find would be detected by all technologies in use, but that is not always the case. Just remember my old adage, “Security doesn’t exist, only speed bumps.” Just like the Great Wall of China was eventually by passed by the Mongol horde, so are digital defenses by digital threats.
It is after this three-step process that we help deliver clean traffic to endpoints, inboxes, shared drives and servers and ensure endpoints stay secure by eliminating threats before they activate. By applying signature-based defenses in front of behavior-based defenses, we are able to protect the world against an onslaught of cyberattacks.
A good real-world example was the initial set of WannaCry attacks. The ransomware attack became famous for taking out 16 NHS hospitals in the UK (secured by a competitor).
However, the NHS sites protected by SonicWall were running without disruption from the attack. We stopped this attack three weeks in advance because our Capture Labs research team created protections against the SMB vulnerability and the WannaCry variant they found in the wild.
So, when the attacks started, they were stopped by internal defenses (e.g., firewalls). But what about Versions 2, 3, 16 or 18, etc.? These were discovered and stopped by Capture ATP.
To better understand how Capture ATP is protecting organizations against attacks like Meltdown, please read our solution brief on Real-Time Deep Memory Inspection.