5.6 Threat Emulation and Threat Extraction

The Problem These Blades Solve

Signature-based Anti-Virus catches known malware. The problem: every day, attackers generate thousands of new malware variants specifically to evade signature databases. By the time a signature exists, the attack is often already in progress. The Check Point SandBlast blades address this gap with two complementary technologies: Threat Emulation (sandboxing) and Threat Extraction (file sanitization).

Both blades run on top of the standard TP stack and are licensed together as SandBlast. They are configured inside the TP profile, separately from Anti-Virus.

Threat Emulation

Threat Emulation detonates files in a virtual sandbox. When a file arrives at the gateway (as an email attachment, an HTTP download, or a file transfer over SMB/FTP), the gateway forwards the file to an emulation environment. The environment runs the file in a virtual machine that mimics a real endpoint — with common operating systems, office suites, and other typical software — and observes what the file does. If the file attempts to modify the registry, drop a payload, contact a C&C, or take any other malicious action, emulation flags it as malware.

Key points for the CCSA:

• Emulation catches zero-day and unknown malware that signature-based AV misses.
• Emulation takes time — typically seconds to a few minutes per file, depending on complexity.
• During emulation, the gateway can either hold the file (block delivery until the verdict is in) or deliver the file and retroactively block the host if emulation later determines the file was malicious.
• Emulation can run in ThreatCloud (files sent to Check Point's cloud sandbox) or on a local SandBlast Appliance (on-premises sandbox). The choice is driven by latency, privacy, and volume requirements.

A common CCSA scenario contrasts the two deployment models: a financial institution with strict data-residency requirements may prefer a local appliance; a small branch office may use the cloud. The trade-off is simplicity (cloud) versus control and privacy (appliance).

Threat Extraction

Threat Extraction takes a different approach. Rather than trying to determine whether a file is malicious, it removes the active content from a document entirely. Active content includes macros, embedded objects, OLE packages, external links, JavaScript in PDFs, and other executable or auto-running elements. The extracted (sanitized) file is delivered to the user as a clean document — same text, same images, no active content.

Key points:

• Extraction is fast — it processes files in near real time, much faster than emulation.
• Extraction is content-preserving — the visible content (text, images) is preserved; only active content is stripped.
• The user can request the original file through a workflow if they need it (often with a click-through warning and a logged approval).
• Extraction catches zero-day document exploits because it does not depend on knowing the file is malicious — it just removes the delivery mechanism.

The combination of Extraction (fast, always-on, removes the threat) and Emulation (slower, gives a verdict on the original) is the heart of the SandBlast design. A common deployment pattern: deliver the extracted file to the user immediately, run emulation on the original in the background, and if emulation confirms the file is malicious, block the host and alert. The user gets a working document immediately, and the gateway still has the verdict for incident response.

File Type Coverage

Emulation supports a defined set of file types — commonly Microsoft Office documents, PDFs, executables, archives (ZIP, RAR), and some scripting formats. The supported list evolves with ThreatCloud updates. Extraction supports a similar set of document types. File types outside the supported list are not emulated or extracted; they pass through (subject to AV and other blades).

CCSA does not require you to memorize the supported list. It requires you to know that emulation and extraction are limited to specific file types and that unsupported file types are not processed by these blades.

Configuration in the TP Profile

Both blades are configured inside the TP profile:

• Threat Emulation section — enable/disable, choose cloud or appliance, decide whether to hold or deliver files pending verdict, set file types to emulate, set max file size.
• Threat Extraction section — enable/disable, choose whether to extract by default or only on-demand, set file types to extract, configure the original-file request workflow.

A typical policy extracts all supported documents and emulates all supported files for external email and web downloads. For internal server-to-server traffic, extraction may be skipped to avoid latency.

Logging and Forensics

Both blades generate detailed logs. Emulation logs include the verdict (malicious/clean/suspicious), the observed behavior, and the file hash. Extraction logs include the original file name, the active content removed, and whether the user requested the original. These logs feed SandBlast-specific SmartEvent views and the ThreatCloud intelligence pool (anonymized).

Common CCSA Scenarios

Typical Threat Emulation and Threat Extraction questions:

• Identify which blade catches zero-day malware in unknown files (Threat Emulation).
• Identify which blade removes active content from documents (Threat Extraction).
• Recognize that the two blades are complementary — Extraction gives the user a safe file quickly, Emulation gives a verdict on the original.
• Recognize the cloud-vs-appliance trade-off for emulation.
• Recognize that file types outside the supported list are not processed.

A representative scenario: a user receives a never-before-seen Word document with an embedded macro that exploits a zero-day vulnerability. Anti-Virus does not catch it. What catches it? Threat Extraction removes the macro immediately, delivering a safe document. Threat Emulation detonates the original and confirms it was malicious. Both blades contribute; signature-based AV does not.