Tuesday, April 14, 2015

My story around Threat Emulation: the issue, the solution, etc.

Some of you may remember my post from 28.03 about Threat Emulation issue I have found by accident.

It took Check Point a couple of weeks to investigate the issue and to provide not just an official response but also an actual solution. Well, let's say they have closed some of the evasion scenarios.

In a nutshell, the issue was about inability to detect a known malicious attachment in a zipped file. In my particular case it was a ZIP file with a plain Java script named as XXXX.doc.js. Although the file has had a minimal obfuscation effort, the main body of the script was a clear text, and the signature was known to be malicious with at least 10 parties in VirusTotal list when I have started investigating the issue.

To make sure why Check Point did not even try to emulate the threat, I have unzipped the file to scan the actual context with Check Point. Apparently CP ignores .js files. Only when I have changed the extension to .doc, it was properly recognised as a malicious. Funny part is, as soon as it is NOT a Java script, it cannot be executed, even by mistake.

Bottomline: Check Point cloud based Threat Emulation solution was ignoring executables of unsupported type if sent in ZIP, although ZIP format was formally a supported type.

Today this loophole is fixed, to a point. Here is the official answer I have got from Check Point Response Team:

As a result of your post we have decided to update our portal and scan all content of zip files and thus detecting also known malicious files that are yet to be supported in full emulation. The fix has been applied, as discussed.

As for our customers, they were never vulnerable to this attack vector by using the Anti-Virus and Anti-Bot software blades.

I have checked, and indeed, the known bad malware is now being detected as part of ZIP files. There is, however, still an issue with the concept of "supported file types" and Threat Prevention.

Same malware will pass TE without detection if sent unzipped. Today Check Point does not emulate Java script files and powershell files. Why? I have no idea. 

The point is, if an attacker sends an attachment as XXXX.doc.js or XXXX.doc.ps1, he can still bypass TE protection easily. To be fair, I am not aware of any other vendor with a Threat Emulation solution that tries to detonate these types of files. It is not specifically a Check Point only problem. Of course some users will click on such a file, the humans are the weakest link in the security anyway.


  1. The reply from Check Point is so funny - if you use our AV solution, you'll be protected. Why do customers need TE in this case???

  2. Hi Michael!

    Please let me elaborate on this.

    Check Point has replied that even before TE was fixed, this particular attack was covered, if a customer complimented TE with AVI blade.

    This statement is not applicable to the case of "unknown bad" when AVI signature is not yet ready. For that particular case TE is must, and today Check Point scans JS files inside ZIP. They do not scan JS files natively, even today.

    Mind, we are only talking about cloud based emulation. I would assume TE appliances are not yet able to scan JS even in archive files.

    1. Hey Valeri,

      Yep, exactly, everything depends on if a customer enabled AV (Kaspersky made in this case) or using a third party solution, and his update. It means, CP TE is for fun only.

    2. Well, AV does not cover unknown bad. Hence TE, but in the presented example it was not covering particular files in archives. Now it does.