Attachment sandbox — detonation on your own server.

How it works

When an attachment raises suspicion — through a reputation score, missing signature, unusual file structure or other indicators — it is not handed straight to the recipient. Instead it runs through an isolated detonation environment that observes the file's behaviour: which processes it tries to spawn, which network connections it opens, which files on disk it touches. The result is matched against curated detection rules.

What the sandbox catches

• Macro malware in Office documents — Word/Excel/PowerPoint with auto-execute macros, PowerShell calls, registry manipulation
• Exploited vulnerabilities in PDFs — JavaScript heap spray, embedded executables, compromised XFA forms
• Nested archives — password-protected ZIPs with the password in the mail body, ZIP bombs, deeply nested archives intended to evade detection
• Living-off-the-land patterns — files that don't do anything "malicious" but use legitimate Windows tools (PowerShell, certutil, mshta) for escalation
• C2 indicators — connection attempts to known command-and-control servers, DNS tunnelling patterns

What the cloud competition does

Vendors like Mimecast, Proofpoint, Hornetsecurity and Microsoft Defender for O365 ship suspicious attachments to their own cloud sandbox in the US or EEA. From a compliance point of view this creates three problems:

• Data flow into the vendor's cloud — the attachment leaves your infrastructure. For sensitive documents (client files, patient records, tax documents, trade secrets) this is a GDPR transfer with a transfer-impact-assessment obligation.
• Latency spike for large files — a 50 MB PDF takes several minutes to upload and round-trip-analyse. Mail sits in quarantine while the recipient waits.
• The vendor sees every customer's attachments — telemetry aggregation as a marketing argument ("we see more threats") is also a privacy risk.

How the sandbox stays isolated

Every detonation runs in its own Linux container-like sandbox with separate mount namespaces, no network access (or, optionally, a controlled outbound tunnel for C2 detection), strict resource limits (CPU, RAM, wall-clock time) and automatic cleanup after every run. Even if a sandbox escape succeeds, the malware cannot leave the sandbox — it runs as an unprivileged user with filtered system calls.

Curated detection rules

The operator can drop their own detection rules in a standard format widely used by the security community. Anyone facing a specific threat (e.g. a targeted phishing wave against their industry) can add their own indicators of compromise without waiting for the vendor. Default rules ship with every update — your own rules survive updates.

What happens to detonated files

• Detection rule matches → mail goes to quarantine, operator + recipient are notified, the sample stays available for forensics
• Suspicious patterns but no match → soft-flag in the header (X-Spam-Sandbox: suspicious), mail goes through but the recipient client may treat it more cautiously
• No indicators → mail goes through normally, the sandbox run is logged in the audit log
• Sandbox timeout → operator policy decides (default: pessimistic, mail to quarantine)

Sandbox detection without cloud data flow?

Suspicious attachments stay on your server. Operator policies define what happens for each verdict.

See pricing