Per IBM X-Force 2025, 99% of cyber attacks arrive through document files. Email gateways already strip executables (.exe) — but macros, scripts, and malicious links embedded inside Word, PDF, and HWP (Hangul Word Processor) documents fall outside what conventional security can catch by design.
Word, Excel, PDF, and HWP files are not simply text and tables. Their formats expose multiple streams capable of executing code. Adversaries plant macros, scripts, embedded OLE objects, and malicious links into those streams so that merely opening the document triggers execution.
Code embedded inside Office documents. A single click on Enable Content can trigger privilege escalation and remote payload download.
The mechanism that lets one file carry another. The canonical path for executables disguised as innocent documents.
Rendering languages used inside HWP and PDF files — the primary vector for recent attacks against regulated public institutions.
Documents configured to fetch content from attacker infrastructure. The malicious payload loads only the moment a user opens the file.
Execution-based analysis — sandboxes and APT appliances — opens a file inside a virtual machine and watches for malicious behavior. But adversaries design malware so that no behavior ever occurs. With nothing to observe, the sandbox has nothing to report.
Malware inspects CPU features, registry keys, and mouse-movement patterns to determine whether it's running inside a VM. If it concludes yes, it stays dormant and exits cleanly — the sandbox logs a benign verdict.
The payload does not execute on open; it waits — 30 minutes, 2 hours, sometimes days — until a timer expires. A sandbox window averages 2–3 minutes; if nothing fires in that window, the verdict is clean.
Malware fires only when a real user would act — scroll to page 3, click a specific button, enable edit mode. There is no human in a sandbox, so the trigger conditions never fire.
All three classes share the same root cause: there is no observable behavior to inspect. Sandboxes are built to watch behavior — the principle itself can't cover this territory.
Detection asks: is this file malicious? CDR asks a different question entirely — are there executable elements inside? If so, remove them.
Pattern match → verdict → allow or block
Disassemble structure → strip executable elements → safely reassemble
Instead of hunting for what is already known, disassemble everything and safely reassemble.
Where a sandbox watches behavior, MARS reverse-engineers the format specification and decodes the structure itself. Because it reads the code without running the file, even malware engineered to hide its behavior cannot slip through — by design.
Records only after the act occurs. An attacker who hides their behavior walks past CCTV in plain sight.
Identifies by composition alone — no behavior required. Dangerous structures reveal themselves without execution.
True file type identified by magic bytes and internal structure — never by extension. 309+ format specs built in.
309 specsEvery internal stream is parsed against the format unit — CFB, OOXML, PDF objects, HWP records.
binary levelExecutable elements — macros, embedded OLE objects, scripts, external resource references — inspected by reading the code itself.
no executionWe disarm, not just detect. Every executable element is stripped under a zero-trust default.
34 msLayout, comments, and hyperlink schema preserved. End users see no difference.
safe.docxCFB, OOXML, PDF, HWP, HWPX, images, archives, and scripts. All major formats — including the HWP family, the primary vector for attacks against regulated public institutions in Korea.
Run a benchmark with your own files and samples. Deploys inline without changes to your existing infrastructure—results report typically within 3 days.
