Compiled HTML Help is a Microsoft help file format that can be abused as a malware container or execution vehicle. In threat campaigns, CHM files are attractive because they can run script-like content, may appear benign to users, and can bypass some controls that focus on office documents.
How Compiled HTML Help becomes an execution vehicle
CHM files are more than passive help documents. They package HTML, navigation data, and support for active content in a format that some users and tools still treat as low risk, which is why threat actors have used them to deliver payloads or start execution chains. Their usefulness to attackers comes from the combination of familiar file type, embedded script-like behavior, and the fact that the content can be opened locally with trusted system components.
That blend of usability and execution potential makes CHM a classic example of a “looks like documentation, behaves like code” problem. The file itself is not inherently malicious, but the format can carry content that runs actions, launches external resources, or guides the victim into a second-stage compromise.
Why attackers use CHM files in campaigns
Attackers favor CHM because it can help them blend into normal workflows. A help file attached to an email, bundled with an archive, or placed alongside legitimate software can appear benign, especially when the user expects product documentation or an installer companion. That social camouflage matters because the user’s trust in the format lowers the chance of caution before opening it.
CHM can also help evade controls that are tuned mainly for office documents, macros, or obvious script files. In practice, that means the payload may slip through policy gaps where defenders focus on the more common attachment types and overlook legacy help containers.
For broad file-type abuse patterns, the W3C is useful as a reminder that browser and web-platform behavior, including locally rendered content, is governed by standards and implementation details that attackers try to exploit.
Defensive controls and detection priorities
CHM should be treated as an executable-risk attachment, not as ordinary documentation. The key control question is whether the environment allows users to open legacy help files from untrusted sources and whether security tooling inspects them with the same scrutiny applied to scripts, archives, and other active-content containers.
Organizations that manage mixed attachment risk often map this problem to NIST SP 800-53 Rev 5 Security and Privacy Controls for access control, system integrity, audit, and configuration management. File-type restriction, attachment inspection, and execution control are all relevant because the format’s danger comes from what it can launch or load, not just what it displays.
When defenders want a more operational view of the abuse pattern, FIRST EPSS is useful for prioritising exploitability in the wider environment, while CHM-specific handling still depends on local mail, endpoint, and browser policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.PT — Protective Technology | CHM abuse is reduced by protective tech that limits risky file execution paths. |
| Recommendation — Restrict legacy help-file execution paths and enforce protective controls on untrusted attachments. | ||
| CIS Controls v8 | 8 — Audit Log Management | Detections for CHM abuse depend on logging file execution and suspicious child processes. |
| 10 — Malware Defenses | CHM is a malware delivery container, so malware prevention and inspection directly apply. | |
| 6 — Access Control Management | Limiting what users can open and execute helps reduce abuse of risky file types. | |
| Recommendation — Log and review suspicious help-file launches, script execution, and follow-on process creation. Inspect and block malicious CHM attachments with malware defenses at mail and endpoint layers. Limit user access to untrusted file types and remove unnecessary execution pathways. | ||
| MITRE ATT&CK | T1204 — User Execution | CHM campaigns commonly depend on a user opening the file to trigger the malicious chain. |
| Recommendation — Hunt for user-execution paths that start from help files and lead to suspicious process activity. | ||
Practitioner Guidance
What to watch for: Treat CHM as a risky attachment class wherever users can receive files from outside the organisation. The strongest warning sign is not the file extension alone, but a CHM delivered in a context where help content is unnecessary or where the file is paired with instructions to open it immediately.
Governance implication: Security teams should decide whether CHM is permitted at all, and if it is, under what conditions it may be opened. That decision belongs in attachment policy, endpoint hardening, and user awareness controls rather than being left to individual judgment at the point of receipt.
Practitioner takeaway: If a help file needs to run active content to be useful, it is already behaving like an execution surface and should be handled with the same suspicion as other interactive payload containers.
Risk and Threat Considerations
CHM files create a practical risk because they can hide executable behavior inside a file type many users associate with documentation. That makes them attractive for phishing and malware delivery, especially where mail and endpoint controls are configured to focus on more obvious attachment formats.
Failure mechanism: The attacker relies on user trust in the help-file format, then uses the container to trigger script-like actions, launch a second stage, or steer the user into opening malicious content outside the help viewer.
Impact: A successful CHM-based delivery can lead to malware execution, credential theft, follow-on payloads, and deeper compromise if the file bypasses front-end screening or reaches an unprotected endpoint.
Framework Alignment
Security teams can use OWASP API Security Top 10 only indirectly here, so it is less central than endpoint and attachment controls; the more direct governance fit is for file trust, execution control, and abuse of user-facing surfaces.
For attachment handling and execution containment, the most relevant operational mapping is to CIS Benchmarks, which support secure configuration choices that reduce the chance of legacy content being opened or executed in a permissive environment.
Where local rendering or browser-integrated content matters, OWASP API Security Top 10 is not the right primary framework, so the better practitioner lens is secure configuration, attachment filtering, and execution restriction rather than application-interface abuse.
