Threat Emulation with HTTP(S) Traffic

SandBlast is wonderful

In my humble opinion, SandBlast Threat Emulation is one of the most effective software blades Check Point has ever built. I saw it rescuing some customers asses in the zenith of Locky & Co.

It is very smart with SMTP and filters out malicious mails in a wonderful way. Nearly one year ago one of our customers was heavy under attack with malicious PDFs coming in to about 1,500 different end users within 10 minutes. The file hash was changing nearly every fifth file. I could easily spot this from SmartLog.

Nothing bad happened to the customer besides some time of mail congestion, but every little piece of malware was sorted out by Check Point SandBlast Threat Emulation. Wonderful, really wonderful.

Do not throw Anti-Virus away

So, if SandBlast Threat Emulation is so wonderful – should you stopp paying for Anti-Virus and completely rely on SandBlast? I would not suggest that. SandBlast Threat Emulation needs a lot of resources because the files may have to be emulated on different operating systems and in different versions of the same programs (Acrobat Reader, Microsoft Office).

That is the reason why hashes of all emulated files are computed and saved for some time. So every file only need to be emulated once. And if a pattern based Anti-Virus could filter out a file before emulation, then the file does not have to be emulated at all. That will be the cheapest way to sort out malware.

Anti-Virus does not recognise enough malware to used as the only solution for this purpose. But Anti-Virus filters enough malware to pay its rent as a part of a bigger solution.

Why HTTP(S) is a problem

HTTP and HTTPS normally are handled different than SMTP. (HTTPS and HTTP are the same after you implemented HTTPS Inspection. So I will only talk of HTTP from now on.)

SMTP is handled best by activating the MTA on the gateway which initiates the threat emulation. The MTA is a Postfix. Mail is accepted by this MTA, stored locally, sent to the emulation, and after that dropped or sent to the recipient. So store-and-forward is a good way to use threat emulation because you do not have to deal with direct user experience. Most end users are used to wait for mails for some minutes, quite often due to greylisting.

HTTP is different. There is a user initiating a download of text or files and he is used to get this data immediately. The user also expects a progress bar of a download to run a kind of evenly to 100 percent.

But what happens when a user starts a download and you want to emulate the file he downloads? In the beginning everything looks quite normal to end user. Progress bar starts and progresses in direction to the end. And when it is nearly at the end, it stops. Why does that happen?

Let us look behind the scenes and towards what the gateway is doing: When passing the traffic to the end user, the gateway takes a copy of each IP packet of the download and reassembles a duplicate of the file. This is necessary because a complete copy of this file is needed for emulation. But when the last IP packet of the download reaches the gateway, this package will not be forwarded to the end user, but only added to the local copy of the downloaded file on the gateway. Then this file is sent for emulation to the SandBlast appliance or to the cloud.

Because we do not know if the file is malicious at this time the last packet is held back at the gateway until we have a result of the emulation. This will take between 1 and 3 minutes if the file is benign and the SandBlast appliance is not overloaded and much longer if the file is considered malicious or the emulation cannot take place because all resources are in use. This is why the progress bar of the end user stops at this moment.

This is the first problem: The typical behaviour of a user with a stuck download connection is to hit reload. This connection looks stuck from the end users perspective. If you do not use a proxy server the same file is downloaded again by the user now and takes bandwidth from the internet connection. If emulation has not ended when the last packet arrives the download connection looks stuck again. This behaviour nearly drives end users mad.

But what happens when the emulation ends? Then the result of the emulation is either benign oder malicious. The file hash of the downloaded file is saved together with the emulation result on the gateway and the emulating SandBlast appliance. This saves emulation ressources for known files for the future. And if the file is benign the last IP packet ist send to the end user and everything is fine again from this moment on.

On the other hand, if the file is classified as malicious, the last IP packet gets dropped by the gateway and the download connection gets resetted.

Second Problem: For the end user there is no difference between a broken download and a download cancelled by the gateway due to malware detection.

Both problems are not Check Point specific and produce a horrific user experience. They are inherent problems of the implementation of HTTP downloads. There is no special control channel for communication of the status within HTTP. Every vendor has to deal with this.

Solutions – or better: Workarounds

What I described above is the operation mode of “Hold”. This means that the connection is paused until emulation ends. That is the most secure configuration. There exist alternatives.

Background Mode

This operation mode lets the connection pass and emulates afterwards. Only when a file is known to be malicious because a corresponding hash exists from a previous emulation it will be blocked. To state it very clearly: malware reaches the end user before it will be classified as such. You will have to investigate where the malware has been gone in the time from detection to removal actions. This method is reactive, not proactive. It is quite comfortable as long as you do not get infected with malware. From the moment of infection it will get very uncomfortable – the more aggressive the malware acts, the more uncomfortable the situation gets for you.

Advantages:
• User experience is much better as with the “Hold” method because the connection is not paused until emulation ends.
• Like in “Hold” mode no changes has to be made to the end users operating environment.
• Like “Hold” mode there are no additional costs to SandBlast Threat Emulation.

Disadvantages:
• There also exists no possibility to send useful messages to end users in case malware was detected. That is the same as with “Hold” mode.
• The first malicious file will be delivered to the end user. Maybe some more files if the file is downloaded by other persons before the emulation has finished. If the retention time of the file hash has ended, the malicious file can be downloaded again.

Browser Plugin (SandBlast Agent for Browsers)

Check Point delivers a browser plugin (sk108695: Check Point SandBlast Agent for Browsers) for Chrome and Internet Explorer 11 (Early Access). This solution uses another way to emulate files. The browser plugin downloads the file (hopefully) without any interference from the gateway to the client. Then it uploads the file via an web API to the emulation appliance and waits for the result. If the file was classified benign it will be presented to the end user, otherwise it will be deleted.

Advantages:
• Good user experience because end user is always informed how the file processing performs.
• No need for HTTPS inspection on the gateway because the plugin sees the file unencrypted.
• Local files can be sent to the emulation via the plugin.
• Plugin can be controlled via Windows Group Policy Objects (GPO).
• No additional costs to SandBlast Threat Emulation.

Disadvantages:
• Changes to each end user computer are necessary.
• Only available for Google Chrome and Internet Explorer 11.
• Only supported for Windows. (Google Chrome plugin works with macOS, too.)
• Mixed operation of browsers with plugin and without plugin will get difficult because some need emulation at the gateway and others must work without emulation interference from the gateway.
• If you rely on the browser plugin you have to guarantee that no users use different browsers. These are often needed for special applications.

SandBlast Agent

SandBlast Agent extends the threat emulation plugin with emulation for:

• Content copied from removable storage devices
• Lateral movement of data and malware between systems on a network segment

By this normal file write operations will be subject to threat emulation. There are many more features which are not part of this article.

Advantages:
• Good user experience because end user is always informed how the file processing performs.
• No need for HTTPS inspection on the gateway because the plugin sees the file unencrypted.
• Local files are subject to emulation on write or copy.
• Plugin can be controlled via Windows Group Policy Objects (GPO).

Disadvantages:
• Changes to each end user computer are necessary.
• Browser plugin only available for Google Chrome and Internet Explorer 11.
• Only supported for Windows.
• Other browsers are supported through emulation of file writes to file systems.
• Additional costs to SandBlast Threat Emulation.

What does other vendors offer?

I am not very experienced on the products of other vendors. What I learned from a training on Ciscos Advanced Malware Protection (AMP): there is no possibility to block malware based on emulation results, neither through direct emulation results nor by using locally generated file hashes. Cisco offers a thing the call “retrospective security”. As far as I understood this, file hashes are saved and if a file will be classified as malicious at a later time, you will know where in your networks this file resides. Then the fun begins, because there exist no automatisms for remediation…

For me the Cisco approach does not make much sense nor offers any acceptable protection. But maybe I got something wrong. So I will be very glad if someone gives me some enlightenment on the perfectness of the Cisco solution or solutions from other vendors.

I must admit: By now, I have not seen anything on the same level than Check Point, neither by product specification nor at our customers sites.