AN0968: Analytic 0968
Execution of hh.exe to open a .chm file followed by suspicious child processes or script engine invocation (VBScript, JScript, mshta, powershell). Behavior includes loading a CHM file from untrusted locations, or immediately spawning commands indicative of payload execution.
Analyst context for executives and security teams
This analytic is about spotting risky Windows Help Viewer activity: hh.exe opening a compiled HTML Help (.chm) file and then launching suspicious child processes or script engines such as VBScript, JScript, mshta, or PowerShell. For leaders, the significance is not the file type itself; it is whether the organization can see trusted Windows utilities being used as a launch point for payload execution from untrusted locations.
Executive priority
Prioritize this as a validation point for endpoint visibility and incident readiness on Windows systems. It helps answer whether SOC and IR teams can reconstruct process chains, identify execution from untrusted file locations, and distinguish normal help-file usage from activity that may require containment. It is also useful evidence for control assurance around script execution monitoring and endpoint logging quality.
Technical view
Validate that Windows telemetry captures hh.exe executions, the .chm file path or source location, parent/child process relationships, command-line arguments, user context, and immediate child processes. Tuning should focus on hh.exe opening CHM files from untrusted or unusual locations and spawning command interpreters or script engines including VBScript, JScript, mshta, and PowerShell. Because ATT&CK does not provide detection logic for this analytic, teams should test local baselines before alerting broadly.
Likely telemetry
- Windows process creation events for hh.exe and child processes
- Command-line arguments and process lineage
- File path and location metadata for opened .chm files
- Script engine execution evidence for VBScript, JScript, mshta, and PowerShell
- User, host, and timestamp context for correlation
Detection direction
- Baseline legitimate hh.exe usage in the environment to reduce false positives from normal help-file activity.
- Alert on hh.exe spawning script engines, command shells, or PowerShell shortly after opening a .chm file.
- Prioritize cases where the .chm file is loaded from untrusted, user-writable, or unusual locations, if that context is available.
- Ensure process lineage is retained long enough for incident responders to reconstruct hh.exe-to-child-process chains.
- Document gaps where endpoint tooling records process starts but not command lines, file paths, or child process relationships.
Mitigation priorities
- Improve endpoint logging coverage for Windows process creation, command line, and process ancestry.
- Restrict or monitor script engine and PowerShell execution according to organizational policy.
- Review controls for execution from untrusted or user-writable locations.
- Use detections like this in tabletop or validation exercises to confirm SOC triage and IR escalation paths.
- Maintain audit evidence showing that relevant Windows execution telemetry is collected and reviewed.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and no ATT&CK tactics or relationship context were provided. The strongest defensive value is in validating visibility into suspicious hh.exe process chains involving CHM files and script or payload execution indicators.
Official detection logic is not provided, and no relationships, procedure examples, mitigations, or data source mappings were supplied. Local environment baselining is required before assigning severity or assuming maliciousness.
Analytic 0968
Execution of hh.exe to open a .chm file followed by suspicious child processes or script engine invocation (VBScript, JScript, mshta, powershell). Behavior includes loading a CHM file from untrusted locations, or immediately spawning commands indicative of payload execution.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | b4e6d118c080… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0968Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.