T1601: Modify System Image
Adversaries may make changes to the operating system of embedded network devices to weaken defenses and provide new capabilities for themselves. On such devices, the operating systems are typically monolithic and most of the device functionality and capabilities are contained within a single file.
To change the operating system, the adversary typically only needs to affect this one file, replacing or modifying it. This can either be done live in memory during system runtime for immediate effect, or in storage to implement the change on the next boot of the network device.
Analyst context for executives and security teams
Modify System Image matters because it targets the operating system image of network devices, where a single monolithic file may control most device behavior. If that image is changed, defenses can be weakened immediately in memory or after reboot from storage, creating risk to routing, segmentation, monitoring trust, and incident containment.
Executive priority
Treat this as a high-value resilience and control-assurance issue for critical network infrastructure. Leaders should ask whether the organization can prove what OS image should be running on key network devices, who can change it, whether unauthorized downgrades or patches would be noticed, and whether audit evidence exists for privileged access, image integrity, and boot integrity.
Technical view
For SOC, detection engineering, and IR teams, validate coverage for the Network Devices platform under the defense-impairment tactic. ATT&CK provides no official detection text, but relates DET0170 as a detection strategy and identifies two sub-techniques: Patch System Image and Downgrade System Image. Practical validation should focus on integrity changes to device images, unexpected image versions, image replacement events, privileged administrative activity, reboot-linked changes, and deviations from approved baselines.
Likely telemetry
- Network device OS image version, filename, checksum, and approved baseline inventory
- Privileged authentication and administrative session logs for network devices
- Configuration and command audit logs related to image, boot, upgrade, downgrade, or file operations
- File transfer or image download activity to device storage
- Boot, reload, and runtime integrity events where available
Detection direction
- Because official ATT&CK detection text is not provided, start by testing whether DET0170-style logic can be implemented from available device telemetry.
- Alert on image hash/version drift from approved baselines, especially downgrades or image changes outside maintenance windows.
- Correlate privileged account use, image file activity, and reboot events to reduce false positives from legitimate upgrades.
- Tune for authorized patch cycles so normal maintenance does not overwhelm analysts, but require evidence linking each image change to an approved change record.
- Check blind spots: devices without centralized logging, missing command accounting, weak image inventory, or no reliable integrity measurement may make this behavior difficult to prove after the fact.
Mitigation priorities
- Prioritize privileged account management: restrict who can administer network devices and require accountability through logging and auditing.
- Enforce MFA and strong password policies for administrative access where supported.
- Protect credentials used for network device administration to reduce the chance that image changes can be performed with stolen access.
- Use code signing and trusted image validation where supported to prevent untrusted or tampered images from running.
- Implement boot integrity controls and routine image baseline verification on critical devices.
Analyst notes and limits
This technique is broader than a normal software update concern because the ATT&CK description emphasizes embedded network devices where the OS and most functionality may reside in one image. The mapped software relationship to DRYHOOK shows ATT&CK has observed software using this technique, but local exposure depends on device estate, administrative controls, and telemetry maturity.
The supplied ATT&CK object does not include official detection guidance. Device-specific logging, secure boot, code signing, and integrity capabilities vary, so local validation is required before claiming coverage.
Modify System Image
Adversaries may make changes to the operating system of embedded network devices to weaken defenses and provide new capabilities for themselves. On such devices, the operating systems are typically monolithic and most of the device functionality and capabilities are contained within a single file.
To change the operating system, the adversary typically only needs to affect this one file, replacing or modifying it. This can either be done live in memory during system runtime for immediate effect, or in storage to implement the change on the next boot of the network device.
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1601.002 | Downgrade System Image Sub-technique | Downgrade System Image subtechnique of this object. |
| Enterprise | T1601.001 | Patch System Image Sub-technique | Patch System Image subtechnique of this object. |
Groups, software, and campaigns
All related ATT&CK context
Mitigation direction
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 | 2.0 | Current bundle | 093df2815674… |
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 T1601Open 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.