Telling the truth about SME life today

How to trap malware in a sandbox

Share on facebook
Share on twitter
Share on linkedin
Share on email

Building a sandbox

Building the sandbox

The threat emulation engine and sandbox is run by a hypervisor, which in turn runs multiple simultaneous environments for file simulation: Windows XP, 7, and 8; Office 2003, 2007, and 2010; and Adobe 9 environments, plus virtualized instances of the most commonly used Office applications such as Word, Excel, and PowerPoint. As the overwhelming majority of modern malware uses social engineering to trick users into clicking plausible-looking attachments or file downloads, inspecting files that use these popular environments and applications offers the best chance of preventing infections.

Selecting files that are deemed suspicious and needing inspection the route into the sandbox happens inline, either at the organisation’s security gateways or in the cloud, using an agent alongside the organisation’s mail server. File selection can even be done with encrypted traffic delivered into the organization over SSL and TLS tunnels, which would otherwise bypass many industry standard security implementations.

The selection process is done using a combination of heuristics and other analysis methods. For example, if instances of the same file have already been cached at the gateway or by the email agent, the system considers that the file may be part of a mass phishing attempt to multiple employees. This approach optimises and accelerates analysis by choosing only suspicious files for deeper inspection. When files are selected, they are then uploaded to the sandbox containing the emulation engine, which runs either on the security gateway or in the cloud.

Threat detection

Files uploaded to the threat emulation engine are copied and launched in the multiple virtual OS and application environments. They are then subjected to a five-stage inspection process by the engine:

1) If the file crashes the virtualized instance of the program, or attempts to unpack and substitute a different document, it is flagged as malicious. Also, if the file attempts to call .dll or .exe files, this signals abnormal, potentially malicious behaviour;
2) The virtual registry is checked for any attempted changes by the file a hallmark of malware and an action that an ordinary document should never attempt;
3) File systems and processes are checked for any attempted changes made by the file as noted above, an ordinary document should not attempt to make changes;
4) The engine checks for any attempts to communicate via the web for example, to contact a command and control centre or download a malicious payload; and
5) Finally, the engine logs and generates a report on all activity done by the file, including multiple screenshots of the sandbox environment and also creates a “fingerprint” for the file that can be used to quickly identify subsequent detections.

Malicious files detected by the engine are quarantined so that they do not reach the user and cannot infect the trusted network. Even malware code that has been developed to detect when it is being executed within a virtualized environment is not immune to sandbox technology. This malware attempts to camouflage its actions or act in a benign way while in the environment in order to avoid detection. However, the cloaking” activity actually helps to identify the file’s malicious intent in that the attempt at disguise can be monitored by the threat emulation engine and logged as a suspicious file activity.

This entire process takes place transparently for the majority of files meaning that even in the rare event that a file is inspected and proven clean?, the intended recipient of the file will not notice any pause in email services. Information about detected file activity is then available to the IT team in a detailed threat report.

Sharing threat information globally

What if, following detection and blocking of a file by emulation, organisations were able to share information about the new threat to help others avoid infection too” After all, the new threat has been fingerprinted and a signature developed for it, meaning that wider infections can be prevented.

This is the principle behind Check Point’s ThreatCloud service, which helps to spread the knowledge acquired about a new enemy. In much the same way that global health organisations collaborate to fight emerging diseases and develop vaccines and other treatments, ThreatCloud’s collaborative approach closes the time window between the discovery of a new attack and the ability to defend against it. 

Once a new threat has been fingerprinted, details of it (including key descriptors such as the IP address, URL or DNS) are uploaded to ThreatCloud and automatically shared with subscribers worldwide. For example, if a new threat is being used as a targeted attack on a bank in Hong Kong and is identified by threat emulation, the new signature can be applied to gateways globally in minutes. By vaccinating organisations against the attack before the infection can spread, threat emulation reduces the chances of an outbreak becoming an epidemic, improving security for all.

So, even with cybercriminals targeting hundreds or thousands of companies, threat emulation can play a key role in protecting organisations against new malware strains and zero-day attacks. Using threat emulation to ?know your enemy” could become one of the strongest methods for securing organisations” networks, creating a new first line of defense against malware.

Tom Davison is the technical director of Check Point

Image Source



Share on facebook
Share on twitter
Share on linkedin
Share on email

Related Stories


If you enjoyed this article,
why not join our newsletter?

We promise only quality content, tailored to suit what our readers like to see!