AN0862: Analytic 0862
Adversary ships a tampered application or update: an updater/installer (msiexec/setup/update.exe/vendor service) writes or replaces binaries; on first run it spawns scripts/shells or unsigned DLLs and beacons to non-approved update CDNs/hosts. Detection correlates: (1) process creation of installer/updater → (2) file metadata changes in program paths → (3) first-run children and module/signature anomalies → (4) outbound connections to unexpected hosts within a short window.
Analyst context for executives and security teams
AN0862 is a Windows detection analytic for spotting potentially tampered software installers or updates. Its business value is in supply-chain and software trust assurance: if an installer, updater, or vendor service replaces program binaries and the first execution quickly launches scripts, shells, unsigned DLLs, or connects to unexpected update hosts, defenders need a way to separate normal patching from a compromised or unapproved update path.
Executive priority
Prioritize this analytic where business continuity depends on trusted Windows software updates, managed endpoint hygiene, and auditable change control. Leaders should ask whether the organization can prove which update sources are approved, whether endpoint and network telemetry can reconstruct installer activity, and whether incident responders can quickly decide if a suspicious update should trigger containment, vendor escalation, or broader software inventory review.
Technical view
For Windows environments, validate correlation across a short time window: installer/updater process creation such as msiexec, setup, update executables, or vendor services; file writes or binary replacement in program paths; first-run child processes or loaded modules that are unusual for that application; signature or unsigned DLL anomalies; and outbound network connections to hosts not approved as update CDNs or vendor infrastructure. Because no separate official detection logic is provided, implementation should be built from the analytic description and tuned against known-good update behavior in the local environment.
Likely telemetry
- Windows process creation events for installers, updaters, setup programs, and vendor services
- File creation, modification, replacement, and metadata changes in program installation paths
- Code signing and module load telemetry, including unsigned or anomalous DLLs
- Child process telemetry for first-run execution, especially scripts or shells spawned by updater or newly installed binaries
- Outbound network connection logs from endpoints, proxies, DNS, firewalls, or EDR
Detection direction
- Correlate process, file, module/signature, and network activity rather than alerting on any single installer action, because legitimate updates commonly write binaries and contact vendor infrastructure.
- Baseline approved updater behavior by product, vendor, path, signer, child process pattern, and network destination to reduce false positives.
- Treat first-run spawning of scripts or shells, unsigned DLL loading, and connections to non-approved update hosts as higher-value pivots for triage.
- Validate visibility gaps: endpoint logging may capture process and file activity while proxy/DNS/firewall data is needed to confirm unexpected update hosts.
- Tune for enterprise software distribution tools and sanctioned patch windows so normal administrative activity does not overwhelm SOC queues.
Mitigation priorities
- Maintain an authoritative list of approved software update sources, vendor CDNs, and expected installer/updater paths.
- Enforce software signing and application control policies where practical, with attention to unsigned DLLs and unexpected module loads.
- Strengthen change management for software installation and update events so SOC and IR teams can compare alerts against approved activity.
- Ensure EDR, endpoint logging, DNS/proxy, and firewall telemetry are retained long enough to correlate installer execution, file changes, first run, and outbound connections.
- Prepare incident response playbooks for suspicious update activity, including endpoint isolation criteria, software inventory scoping, vendor validation, and rollback decisions.
Analyst notes and limits
This analytic is useful as a correlation pattern rather than a standalone indicator. The key decision point is whether the organization can join endpoint execution, file integrity or metadata changes, code-signing/module evidence, and network destination context around software updates. Relationship context was not supplied, and tactics are not specified, so this take avoids mapping it to a specific ATT&CK tactic or claiming adversary use beyond the official description.
The supplied object has no official detection field beyond the description, no relationships, no aliases, and no tactic mapping. Coverage and accuracy depend on local Windows telemetry, known-good updater baselines, approved host inventories, and change-management data. This summary does not assert active exploitation, attribution, impact, or guaranteed detection.
Analytic 0862
Adversary ships a tampered application or update: an updater/installer (msiexec/setup/update.exe/vendor service) writes or replaces binaries; on first run it spawns scripts/shells or unsigned DLLs and beacons to non-approved update CDNs/hosts. Detection correlates: (1) process creation of installer/updater → (2) file metadata changes in program paths → (3) first-run children and module/signature anomalies → (4) outbound connections to unexpected hosts within a short window.
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 | 2cde9523866c… |
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 AN0862Open 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.