AN0108: Analytic 0108
Executables written or modified in installer directories (e.g., %TEMP% subdirectories or Program Files installer paths) followed by execution under elevated context. Defender observes abnormal file replacement activity, process creation by installer processes pointing to attacker-supplied binaries, and unexpected module loads in elevated processes.
Analyst context for executives and security teams
This analytic focuses on a Windows pattern where an executable is written or changed in installer-related locations and then run with elevated privileges. The business significance is privilege abuse and software installation trust: if attackers can swap or introduce binaries in places administrators or installers use, they may turn routine installation activity into elevated code execution. Leaders should treat this as a control-validation use case for endpoint telemetry, installer hygiene, and incident response readiness rather than as a standalone claim of compromise.
Executive priority
Prioritize this where Windows endpoints and servers rely on frequent software installation, self-updaters, or administrative deployment workflows. The key business question is whether the organization can prove when installer directories are modified, who or what made the change, and whether the resulting executable ran with elevated context. This supports operational resilience, audit evidence for privileged activity monitoring, and faster incident decisions when suspicious installer behavior appears.
Technical view
For SOC and detection engineering teams, validate coverage for Windows file creation/modification in installer directories such as temporary installer subdirectories and Program Files installer paths, followed by process creation under elevated context. The supplied ATT&CK description also calls out abnormal file replacement activity, installer processes launching attacker-supplied binaries, and unexpected module loads in elevated processes. Because no official detection logic or tactic mapping is provided, build this as a behavior correlation rather than a single event rule: file write or replacement in installer path, parent/child process lineage involving installer processes, integrity/elevation context, and module-load anomalies in elevated processes.
Likely telemetry
- Windows file creation and modification events for installer-related directories
- Process creation telemetry with command line, parent process, user, and integrity/elevation context
- File replacement or overwrite evidence, including path, hash, signer, and timestamp where available
- Module load telemetry for elevated processes
- Endpoint security alerts or EDR events related to suspicious installer or updater behavior
Detection direction
- Correlate executable writes or modifications in installer directories with subsequent execution under elevated context.
- Baseline legitimate installer and software deployment behavior to reduce false positives from patching, upgrades, and enterprise software distribution.
- Review parent-child process relationships where installer processes launch unexpected binaries or binaries from temporary locations.
- Tune for abnormal file replacement, unsigned or unusual executables, unexpected hashes, and module loads in elevated processes where telemetry supports it.
- Validate blind spots: lack of file-write logging, missing process integrity level, incomplete command-line capture, or no module-load visibility will materially reduce confidence.
Mitigation priorities
- Restrict write access to installer and application directories to appropriate administrative or deployment identities.
- Harden software installation and update workflows so only trusted, approved installers and deployment tools can introduce executables.
- Enforce least privilege for users and service accounts involved in installation activity.
- Use application control, code signing validation, or allowlisting where operationally feasible to limit execution of unexpected binaries from installer locations.
- Maintain patching and software deployment records so SOC teams can distinguish authorized installer activity from suspicious replacement or execution patterns.
Analyst notes and limits
This object is a detection analytic for Windows only. It describes a useful behavioral pattern but provides no official detection implementation, no tactic mapping, and no relationship context. Glexia would use it as a validation prompt for endpoint visibility, privileged execution monitoring, and installer workflow governance.
The supplied ATT&CK fields do not identify associated techniques, tactics, adversaries, malware, campaigns, mitigations, or active exploitation. Any severity, detection fidelity, or exposure assessment requires local telemetry, asset context, and knowledge of legitimate software installation processes.
Analytic 0108
Executables written or modified in installer directories (e.g., %TEMP% subdirectories or Program Files installer paths) followed by execution under elevated context. Defender observes abnormal file replacement activity, process creation by installer processes pointing to attacker-supplied binaries, and unexpected module loads in elevated processes.
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 | 8a9dac545cef… |
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 AN0108Open 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.