Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

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.

EnterpriseT1601TechniqueObject v2.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

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.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

2 rows
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.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S9013: DRYHOOK

DRYHOOK is Python script used to steal credentials. DRYHOOK was first reported in January 2025, and has previously been leveraged by People's Republic of China (PRC) state-affiliated threat actors identified as UNC5221 and SYLVANITE.[1][2][3]

LinuxNetwork Devices
Relationship explorer

All related ATT&CK context

Mitigations

Mitigation direction

Change history

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 .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
093df28156749f5b...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 093df2815674…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack T1601
    Open source URL
Source and licensing

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.