CHM and RAR attachments remain effective because they reduce user suspicion and can bypass some static inspection workflows. RAR files hide the payload from simple scanning, while CHM files can execute code with low interaction and may evade controls that expect modern document formats. Attackers also pair them with obfuscation, decoys, and legitimate-looking lures to increase the chance of execution.
Why these attachment types still work
CHM and RAR remain useful to targeted espionage operators because they exploit a simple reality: users still judge attachments by familiarity, not by internal structure. A compressed archive looks routine, and a compiled help file can appear like a legitimate support artifact. That first impression matters because it lowers hesitation long enough for the payload chain to start.
They also survive because security stacks are uneven. Some filters focus on office documents, links, or macros, while archives and help files may receive less scrutiny or only partial detonation. Even when controls do inspect them, nested content, embedded executables, or deceptive naming can make the true payload harder to classify quickly.
The OWASP API Security Top 10 is not about attachments, but the same operational lesson applies: attackers prefer delivery paths that create ambiguity in what is actually being executed or trusted. For espionage, ambiguity buys time, and time buys execution.
What makes CHM and RAR useful in the intrusion chain
RAR is effective because it can conceal multiple files, rename payloads, and place malicious content behind an extra extraction step. That extra step is not just friction for defenders, it is a control break when scanning happens before extraction or only on the outer archive. Password-protected archives add another layer of blind spot if the gateway cannot inspect the contents.
CHM remains attractive because it is a legitimate Windows format that some users and controls still treat as low risk. In targeted campaigns, it is often paired with a lure so the user opens a help-like file expecting instructions, then the embedded content or script launches the next stage. The format’s age works in the attacker’s favour because legacy trust assumptions can outlive modern detection tuning.
When the campaign depends on delivery rather than loud exploitation, the objective is not to trigger obvious malware signatures, it is to reach an initial execution state with the least possible noise. That is why attackers often combine archive nesting, misleading filenames, and decoy content with the attachment type itself. The container is part of the disguise, not merely the carrier.
For comparison, the NIST SP 800-53 Rev 5 Security and Privacy Controls maps well to the defensive problem here because controls around content inspection, integrity checking, and malicious code prevention are exactly where these delivery methods try to create gaps.
How defenders should read the pattern
These attachment types do not succeed because they are magical, they succeed because they exploit workflow assumptions. If the email gateway, sandbox, or endpoint policy treats “archive” or “help file” as inherently benign, the attacker only needs one weak layer to let the chain continue. The real question is not whether CHM or RAR is dangerous in isolation, but whether the organisation has controls that inspect the unpacked or rendered content with the same seriousness as the original message.
Current defence guidance increasingly favours layered inspection, file-type normalisation, and stricter attachment handling for high-risk populations. That matters most in targeted espionage, where the lures are tailored to the recipient and the payload is often chosen to fit the victim’s expected workflow. The more believable the delivery path, the more likely a manual review or automated rule will underreact.
Where organisations rely on broad allowlists or legacy trust rules, archive-based delivery and uncommon Windows document types remain a practical bypass. The control failure is usually not a single missed signature, but a mismatch between what the security stack expects to see and what the attacker has actually packaged.
Practitioner takeaway: treat CHM and RAR as delivery containers whose risk comes from inspection gaps and user expectation, not from the file extension alone; if your controls only judge the outer wrapper, attackers will keep using wrappers.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 9 — Email and Web Browser Protections | Targets malicious attachment delivery and phishing-style initial access paths. |
| CIS 10 — Malware Defenses | Addresses detection and blocking of malicious payloads hidden in archives and help files. | |
| CIS 16 — Application Software Security | Supports limiting risky file handling and execution paths used by weaponised content. | |
| Recommendation — Harden mail and browser controls to reduce execution of weaponised attachments. Scan archives and uncommon file types after extraction and before execution. Restrict execution of untrusted content and monitor unusual child-process launches. | ||
| NIST CSF 2.0 | PR.PT — Protective Technology | Covers technical safeguards that stop or contain malicious attachment execution. |
| DE.CM — Continuous Monitoring | Supports detecting suspicious archive extraction and help-file execution patterns. | |
| Recommendation — Use protective technology to inspect, block, and contain suspicious attachment content. Monitor endpoint and email telemetry for archive unpacking and anomalous file execution. | ||
| MITRE ATT&CK | T1566.001 — Phishing: Spearphishing Attachment | Directly matches targeted campaigns that deliver payloads through malicious attachments. |
| Recommendation — Map attachment-based lures to T1566.001 and hunt for follow-on execution activity. | ||
Related resources from NHI Mgmt Group
- Why do malicious macOS campaigns that use fake software updates and developer-targeted lures remain effective?
- Why do crypto fraud campaigns remain effective against legacy email security?
- Why do compromised websites remain effective malware delivery points?
- Why do malvertising campaigns remain effective against enterprise users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
