Sandbox technology. Check Point SandBlast. Part 2

We continue the topic of network sandboxes. In the previous module, I have already given a small “sad” statistics targeted attacks. Summarizing the above, we can draw several main conclusions:

• 99% of malware were seen only once. For this reason, signature protection is simply powerless.
• Mail is a hacker's favorite tool. As a rule, malware is delivered as files or as links to files.
• Contrary to popular opinion, not only exe, flash and java files can be infectious. Those. banning this type of files, you are still not protected. The malware can be hidden in authorized documents such as: doc, excel, pdf, powerpoint, archives, and so on.

In this regard, a relatively new type of remedies appeared ...

Sandbox
')
The current day is probably the only way to deal with zero-day attacks. What actually is the task of the classic sandbox? Next, there will be a lot of pictures from the presentation and, as usual, the video at the end (both theoretical and practical).


Sandbox task is very simple:

• Open file (even infected)
• Analyze activity (changes in the registry, changes in network activity, file system activity, launch of system processes, etc.)
• Block or skip file

Naturally, all actions take place in a virtual machine in specially prepared images. It would seem that here it is a victory over zero-day attacks. But not everything is so simple.

Sandbox circumvention technologies

As soon as the sandboxes were announced as a new means of protection, the so-called “Arms Race” began. Hackers began to write more intelligent malware:

• For example, the malware could go into hibernation and not start immediately so that the sandbox could skip this file further into the network. Sandbox developers immediately responded and began to speed up time in virtual machines. To which hackers responded using their own timers inside the malware (usually running some kind of “more” calculation inside the program), i.e. stopped looking at the system clock.
  
  
• Then, malware began to try to find the sandbox, i.e. determine where they started. Sandboxes began to try to hide the fact of their presence by emulating a physical CPU. But the malware quickly learned to identify this emulation.
  
  
• Newer versions of malware began to try to find a person at the computer, i.e. try to determine that they are not launched by a robot. These were various sensors of mouse movement, keyboard presses, etc. Sandboxes began to imitate human behavior. But it is very difficult. Malware has become quite easy to identify a “virtual” person. For example, one of the malicious programs was packed into a doc format document, where in the middle of the document a picture with a naked woman was inserted. Any healthy person while viewing the document lingered on this picture. The sandbox didn’t do this and simply scrolled the file, imitating human behavior. Thus, the malware easily determined that it was opened by a robot, i.e. sandbox.

This “arms race” is still ongoing.

Check Point SandBlast

In connection with the problems voiced above, recently a new sandbox technology was introduced - CheckPoint SandBlast.



This technology provides a very wide range of protection means:

1. Threat Emulation - file emulation technology
2. Threat Extraction - file cleaning technology
3. Zero Phishing - Phishing Protection
4. Endpoint Forensics - IS Incident Investigation Module
5. Zero Ransomware - protection from cryptographers

In this article and lab, we will focus on Threat Emulation (i.e. file emulation) and Threat Extraction (i.e. file cleanup).

Features of Threat Emulation

What is the feature of Check Point emulation technology? How does she cope with the previously voiced "arms race"? Let's take a look at the work of the Threat Emulation module using the example of a typical life cycle of almost all malware.

1. The first thing that begins the process of delivering malware is with any software vulnerability . There are thousands of these vulnerabilities, it all depends on the software you use (it could be a browser, acrobat reader, email client, etc.). Most of these vulnerabilities are unknown even to software vendors themselves, otherwise they would have released a patch (which they periodically do), but this is almost always after someone took advantage of this vulnerability.
   
   
2. In order to use these vulnerabilities, you need special exploits . Those. mini-programs that perform a certain sequence of actions can get a certain level of access to the victim's system. There are very few exploits and new ones appear extremely rarely.
   
   
3. An exploit can carry within itself the so-called shellcode (i.e., another mini program that will be executed directly on the victim's computer). Typically, this shellcode is used to download additional malware, or to create malware directly on the victim’s computer using “available tools”. A little later, consider how this happens.
   
   
4. Shellcods use various protection bypass techniques.
   
   
5. As a result, we get a huge number of possible variations of malware. Which will also have different sandbox traversal techniques.

Classic (traditional) sandboxes start working at this stage. Such sandboxes are also called OS Level . At the same time, it is likely that the sandbox will not be able to cope with such a number of malware types.

The checkpoint approach is more logical in this case. It is much more reasonable to intercept malicious programs where there are the least of their options and the likelihood of determining them to strive for 100%. This is a stage of exploits.

The checkpoint at the processor level sees the execution of the exploit and allows you to lock the file before executing or downloading additional modules. This revolutionary approach ( CPU Level ) became possible after the appearance of Intel Haswell processors, where such monitoring is allowed at the hardware level. Moreover, checkpoint supports the classic sandbox mode, i.e. OS Level.

Let's now see how the collection of the necessary shellcod actually looks like.


Let's start with the fact that transferring a malicious file entirely to the victim’s computer is very primitive, because in this case, various antiviruses or IPSs can determine the attack. Therefore, hackers invented a rather interesting way. They began to collect malicious code directly on the victim's computer using already running processes. This method was called ROP , i.e. return oriented programming . On this slide you can see how the code is collected for the malware. Presented here is the work of Adobe Reader in hex form. The necessary functions are highlighted and the so-called gadget is assembled. It is this process (improper use of the program) that allows you to see and prevent Threat Emulation. We will not consider ROP in detail, because This is a very complex topic and deserves a separate series of articles.

Traditional sandbox problems

Now let's look at the main problems of traditional sandboxes.



The main problem of sandboxes is that not only infected files come to analysis, but also ordinary, clean files (this also applies to Threat Emulation). After that the emulation process takes place. This process is not instantaneous and can take from 1 to 30 minutes. At the same time, no one eliminates false positives, when a normal file will be mistaken for malicious and discarded. As a result, we have a bunch of irritated users who do not want to wait for their files.

As a result, most sandboxes are configured in bypass mode, i.e. source files reach users while emulation is in progress. And this is the usual detection, not blocking. This is unacceptable in the case of cryptographers, since then it will be too late.

Threat Extraction technology is designed to solve this problem.

Benefits of Threat Extraction

This technology is designed for instant cleaning of files and sending it to the user. At this time, the source file is emulated using the Threat Emulation module.



There are two main ways to clean incoming files:

1. The first is the conversion of the source file to pdf. In fact, there is a “printout” of the file on the virtual printer. The user receives a pdf document with no dangerous content. In 90% of cases this is enough for the user to read the document.
2. The second way is to clear all active content from the source file. All macros are cut out and the output is a completely sterile file with the original extension preserved (doc, ppt, etc.).

I highly recommend to pay attention to the first method, since in this case, the malware does not have the slightest chance of survival. It is safer to just print the file on real paper.

In addition, the user still retains the ability to get the source file if false positives still occur, or if the source document contains important macros (well, for example an excel file with macros). If you take for example files that were received by mail, then the user will be provided with already cleared files with a link to the source file.



If you click on this link, the user will be taken to a special portal, where he will have the opportunity to request the source file. At the same time, he will be warned about its possible harmfulness. Whether the user will receive this file already depends on the settings. You can issue these files manually after a more thorough analysis by information security administrators.

Check Point SandBlast Product Line


If we consider the CheckPoint SandBlast product line, we can distinguish 4 areas. It:

1. Network devices to protect the perimeter or any segments
2. Agents to protect endpoint workstations
3. Cloud protection for Office 365 (Gmail support is expected soon)
4. And a specialized API that allows you to use the cloud checkpoint third-party applications and manufacturers

In this case, as can be seen from the picture, each solution has a different functionality. In this part we will focus on the first option, i.e. network level security. There are three deployment options for network level security:

1. Using the cloud sandbox. The NGTX license is activated on the existing CheckPoint Gateway. Files are sent to emulate to the cloud. In my opinion this is the most optimal and economical option. However, in some companies it is forbidden to send your own files to the external network, even for analysis.
   
   
2. Local sandbox. A separate piece of hardware is used - SandBlast Applince. In this case, the Check Point Gateway with NGTX licenses sends the file to your SandBlast device, where the files are checked.
   
   
3. Local sandbox in inline mode. It is suitable if you do not have a Check Point Gateway.

Now we can move to the lab and in practice try out the Threat Emulation and Threat Extraction solutions.

Video Course for the second part

All the above theory. part can be viewed in video format:


In addition, there are three laboratory works:

Lab №3


In the course of this tutorial, we will configure the Threat Emulation blade (the cloud version) and try to simulate the passage of infected files through the gateway. Then we will again analyze the logs and block the download of malicious files for the Win7 user.

Lab №4


This time we will consider a variant of local emulation, i.e. without sending files to the cloud. We will also try checking email messages, for this we set up Check Point as MTA, i.e. mail transfer agent. Then we will try to send the infected file by mail and make sure that it is blocked. And of course, let's analyze the logs.

Lab №5


As we saw in the last lesson, file emulation is a very effective means of protection, but it takes some time! Especially for those who do not like to wait until the files are emulated, there is a technology called Extraction. During the lesson, we will activate it and try to mail the infected file again. As a result, we need to get the already cleaned, or rather converted, document in pdf format.

To be continued…