AN1480: Analytic 1480
1) New or updated software is delivered/installed from atypical sources or with signature/hash mismatches; 2) installer/updater writes binaries to unexpected paths or replaces existing signed files; 3) first run causes unsigned/abnormally signed modules to load or child processes to execute, optionally followed by network egress to new destinations.
Analyst context for executives and security teams
This analytic is about spotting suspicious Windows software delivery or update activity: installers arriving from unusual sources, signature or hash mismatches, binaries written to unexpected locations, signed files being replaced, and abnormal first-run behavior such as unsigned module loads, child processes, or new outbound network connections. For leaders, the value is in validating whether software installation and update paths are observable and governed, because weak visibility here can undermine trust in endpoint software and complicate incident response decisions.
Executive priority
Prioritize this as a software trust and operational resilience control area. Executives should ask whether the organization can prove where Windows software and updates came from, whether expected code-signing and file-integrity checks are monitored, and whether SOC and IR teams can quickly distinguish normal update behavior from suspicious installer activity. This supports vulnerability management, compliance evidence, and incident decision-making, but the supplied ATT&CK object does not specify a tactic, associated technique, threat actor, or confirmed exploitation scenario.
Technical view
For Windows environments, validate collection and correlation around installer and updater execution, file writes and replacements, code-signing status, hash reputation or allowlist mismatches, module loads, child process creation, and first-run network egress. Detection engineering should focus on behavior chains rather than any single event: atypical source plus signature/hash issue, unexpected write path or replacement of signed files, then abnormal module loading, child process execution, or outbound connections to new destinations. Because ATT&CK provides no official detection logic for this analytic, local baselining of legitimate software deployment and update tools is required.
Likely telemetry
- Windows process creation events for installers, updaters, and child processes
- File creation, modification, and replacement events in software installation paths and unexpected directories
- Code-signing and certificate validation metadata for installers, binaries, and loaded modules
- File hash inventory or allowlist comparison data
- Module/DLL load telemetry showing unsigned or abnormally signed modules
Detection direction
- Baseline approved Windows software sources, update mechanisms, installation paths, and expected signer/hash values before alerting on deviations.
- Correlate atypical software source, signature/hash mismatch, unexpected binary write or signed-file replacement, and first-run execution behavior to reduce false positives.
- Tune for legitimate enterprise software distribution, patching, and self-update workflows, which may otherwise look unusual without source and signer context.
- Review blind spots in endpoint telemetry: lack of module-load visibility, missing code-signing metadata, weak file integrity monitoring, or network logs that cannot identify new destinations.
- Because no ATT&CK relationships or official detection query are supplied, avoid assuming coverage against a specific technique or adversary behavior without local validation.
Mitigation priorities
- Maintain an approved software source and update inventory for Windows systems.
- Enforce code-signing, hash validation, and software allowlisting policies where operationally feasible.
- Restrict software installation and update privileges to managed channels and accountable administrative roles.
- Monitor integrity of trusted installation directories and signed application files.
- Ensure incident response playbooks include verification of installer provenance, signer status, file replacement activity, and first-run network behavior.
Analyst notes and limits
This object is a detection analytic, not a technique description. Its decision value is strongest for organizations that need confidence in Windows software supply, update trust, and endpoint change visibility. The analytic should be implemented as a correlation pattern and validated against normal enterprise software deployment behavior.
The supplied ATT&CK fields include no tactic, no official detection text, no related techniques, no relationships, and no external references beyond MITRE. Conclusions are therefore limited to the stated Windows analytic description and require local environment evidence for prioritization, tuning, and coverage claims.
Analytic 1480
1) New or updated software is delivered/installed from atypical sources or with signature/hash mismatches; 2) installer/updater writes binaries to unexpected paths or replaces existing signed files; 3) first run causes unsigned/abnormally signed modules to load or child processes to execute, optionally followed by network egress to new destinations.
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 | aeca285b6ebf… |
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 AN1480Open 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.