AN0445: Analytic 0445
Detection of msiexec.exe execution where command-line arguments reference remote MSI packages, UNC paths, HTTP/HTTPS URLs, or DLLs, correlated with subsequent module loads and/or network connections to previously unseen destinations. The behavioral chain links process creation of msiexec.exe with suspicious parameters, network activity to retrieve payloads, and module loading indicative of malicious installation or DLL execution.
Analyst context for executives and security teams
This analytic matters because msiexec.exe is a legitimate Windows installer that can also be abused when it is used to fetch or execute remote MSI packages, UNC paths, HTTP/HTTPS URLs, or DLL-related content. For leaders, the practical question is whether the organization can distinguish normal software installation activity from suspicious installer-driven payload retrieval and execution before it becomes an incident-response problem.
Executive priority
Prioritize validation where Windows endpoints can install software or reach external/internal file locations. This behavior affects operational resilience because malicious or unauthorized installer activity can blend into routine administration. Executives should ask whether SOC teams have process, command-line, network, and module-load visibility for Windows systems, and whether software installation baselines are understood well enough to support defensible alert triage and audit evidence.
Technical view
For SOC and detection teams, validate a Windows detection chain that starts with process creation for msiexec.exe and suspicious command-line arguments referencing remote MSI packages, UNC paths, HTTP/HTTPS URLs, or DLLs. Correlate that process activity with subsequent network connections to previously unseen destinations and module loads that may indicate malicious installation or DLL execution. Because no ATT&CK tactic or relationship context is supplied, treat this as a behavior-focused analytic rather than a fully scoped technique mapping.
Likely telemetry
- Windows process creation events including executable name and full command line
- Parent/child process context for msiexec.exe
- Network connection telemetry from the endpoint, including destination host, IP, URL, protocol, and first-seen or rarity context
- Module load telemetry associated with msiexec.exe or related child processes
- File path evidence for UNC paths and remote MSI references
Detection direction
- Confirm that msiexec.exe command-line arguments are captured completely; truncated command lines will materially weaken this analytic.
- Tune for remote references such as UNC paths, HTTP/HTTPS URLs, remote MSI packages, and DLL-related arguments rather than alerting on all msiexec.exe execution.
- Correlate process creation with network activity and module loads to reduce noise from legitimate installations.
- Build allowlists or baselines for approved software deployment systems, package repositories, administrative shares, and expected installer behavior.
- Review false positives from IT software distribution, patching, helpdesk activity, and enterprise application deployment workflows.
Mitigation priorities
- Establish and document approved software installation paths, repositories, and deployment mechanisms for Windows endpoints.
- Restrict unauthorized software installation and remote package execution where business operations allow.
- Harden endpoint controls and policy so msiexec.exe usage aligns with administrative intent and least privilege.
- Ensure Windows endpoint logging captures process command lines, network connections, and module loads needed for investigation.
- Integrate detection results with incident response playbooks that verify the package source, parent process, destination reputation or novelty, and whether unexpected modules were loaded.
Analyst notes and limits
The supplied object is a detection analytic for Windows focused on suspicious msiexec.exe execution with remote package or DLL references, correlated with network and module-load behavior. There are no supplied ATT&CK relationships, aliases, labels, tactics, or separate official detection text, so the take is intentionally centered on validation of the described behavior and the telemetry required to make it operational.
This assessment is limited to the supplied official STIX fields, external reference, and empty relationship context. It does not establish active exploitation, attribution, impact, prevalence, or guaranteed detection coverage. Local baselines for approved installer activity and previously unseen destinations are required before this analytic can be tuned reliably.
Analytic 0445
Detection of msiexec.exe execution where command-line arguments reference remote MSI packages, UNC paths, HTTP/HTTPS URLs, or DLLs, correlated with subsequent module loads and/or network connections to previously unseen destinations. The behavioral chain links process creation of msiexec.exe with suspicious parameters, network activity to retrieve payloads, and module loading indicative of malicious installation or DLL 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 | dc5351e96905… |
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 AN0445Open 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.