---
{
  "title": "Modify System Image",
  "summary": "System-image modification alters embedded or network-device operating software.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1601"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1601: Modify System Image",
      "url": "https://attack.mitre.org/techniques/T1601"
    }
  ],
  "editorialVersion": 2
}
---

## Network-device software is part of the trust boundary

System-image modification changes operating software on embedded or network devices. Unauthorized patching or replacement can weaken defenses or introduce capabilities. In this context, the image is the device's operating software, not simply a cloud template or ordinary container image.

The distinction matters because investigation and recovery may require device-specific expertise and vendor-supported methods. A file replacement on a network appliance can affect routing, filtering, management, or visibility across many connected systems.

## A device runs an unexpected image

In a fictional network, an appliance reports a software version or integrity result that differs from the approved baseline. The analyst works with the device owner to review image identifiers, update history, management records, configuration, and any supported integrity evidence.

An approved upgrade, rollback, or recovery operation could explain the difference. Compare the exact artifact and change with the authorized maintenance plan. A version string alone is not complete proof of image integrity because it is information reported by the device or its software.

The team checks whether the change affected stored software, running state, or the next boot path where evidence allows. Those states can differ, and an image present in storage does not automatically establish which code executed during the incident.

## Use independent and trusted comparison material

Obtain approved software and verification information through a trusted vendor or organizational process. Preserve relevant device evidence before replacing the image where practical. Avoid unsupported acquisition or modification steps that could damage the appliance or destroy remaining context.

[[network-boundary-bridging]] explains why a compromised enforcement device can affect traffic restrictions. [[rootkit]] and [[pre-os-boot]] describe related trust concerns, but they should not be assumed from an image discrepancy alone.

Review management access and the identity that performed changes. Restoring the approved image without restricting the abused administration path may allow the same modification again.

## Recover the device and its relationships

Coordinate containment and restoration with network owners because an appliance may support essential connectivity. Verify the approved image, configuration, management access, and relevant traffic enforcement after recovery.

Assess what the device could observe or influence during the affected period, while distinguishing potential reach from confirmed actions. Missing device logs may limit conclusions and should remain explicit.

For practice, compare an approved firmware rollback with a fictional unreviewed image replacement. Identify authorization, artifact provenance, device-state, and independent integrity evidence. Explain why a familiar displayed version cannot alone establish trust. [[incident-response]] and [[incident-reporting]] connect the device finding to coordinated recovery and a cautious impact assessment.

## Related concepts

- [[mitre-attack]]
- [[logs-and-telemetry]]