MITRE ATT&CK T1601 Modify System Image: Detecting Control Tampering

Modify System Image (T1601) is the network device equivalent of a rootkit: the adversary changes the operating system file of a router, firewall or appliance so the device does what they want while still looking healthy to its administrators. ATT&CK v20 places T1601 in the Defense Impairment tactic (TA0112) for network devices, with two sub-techniques: T1601.001 Patch System Image and T1601.002 Downgrade System Image. Because most network operating systems are monolithic, often a single file, one change can weaken encryption, bypass authentication or add a backdoor, and configuration reviews will not show it. This page covers how the technique works, the cases ATT&CK and vendors document, how to verify images in storage and in memory, the v20 mitigations, safe testing and the identity clean-up that follows a confirmed compromise. It is written for network engineers, incident responders and detection teams. For edge appliances in general see the Edge Device Security Guide; this page stays on the technique.

Key takeaways

• Configuration review cannot see it. A patched image can report a clean configuration while running attacker code, so integrity checks must examine the image file and, where possible, the running memory.
• Two ways in: storage or memory. ATT&CK describes changing the image file to load at next boot, or changing the running image in memory with debug commands or a compromised boot loader (T1542.004 ROMMONkit).
• Downgrades are a quiet variant. T1601.002 installs an older, legitimately signed image with weaker ciphers and fewer defences, so signature checks alone may pass.
• Signed images and secure boot are the v20 answer. M1045 Code Signing and M1046 Boot Integrity sit alongside four mitigations that protect device administration: M1026, M1027, M1032 and M1043.
• Assume every stored secret is exposed. When an appliance image is confirmed modified, rotate the service account credentials, keys and certificates it held, not only the device's own passwords.

What T1601 is

ATT&CK describes Modify System Image as changing the operating system of embedded network devices to weaken defences and add capabilities. Because functionality is concentrated in one file, the adversary typically only needs to replace or modify that file. ATT&CK lists the defences that can be impeded: encryption (T1600 Weaken Encryption is the usual partner), authentication (T1556.004 Network Device Authentication) and perimeter controls through boundary bridging (T1599).

How adversaries use it: real cases

• SYNful Knock (S0519): ATT&CK v20 describes it as malware inserted into a network device by patching the operating system image, citing Mandiant and Cisco. Cisco's analysis says SYNful Knock cannot survive installation of a known-good image.
• The wider Cisco IOS series: Cisco's account of attacks on IOS devices describes 2011 to 2012 patches to images on 2800 and 3800 routers that weakened Diffie-Hellman key exchange, 2013 in-memory modifications on 7600 routers that copied matching packets to an attacker address and provided NAT-style access, and a late-2014 sample that modified ROMMON so it survived reloads and IOS upgrades. Cisco found no evidence of vulnerability exploitation in these cases; the data pointed to compromised administrator credentials or physical access to devices or images.
• DRYHOOK (S9013): v20 records DRYHOOK modifying the Ivanti Connect Secure authentication Perl module DSAuth.pm. Google's January 2025 analysis says it wraps the sign-in functions to capture usernames and passwords from successful logins, writes them encrypted to a file in /tmp, and kills cgi-server processes so the modified module loads. The same analysis describes the attacker recalculating hashes and re-signing the Integrity Checker Tool manifest in an attempt to evade it. Background is in the UNC5221 (Ivanti exploitation) threat actor profile.
• Earlier Ivanti compromises: the Ivanti Connect Secure exploitation 2024 page describes a patched dsls binary that stopped redacting sensitive data, exposing stored service account credentials, API keys and certificates, and CISA's warning that the vendor integrity checker failed to detect that compromise.

The lesson across all four: integrity checking that runs on the device and trusts the device can be subverted. Verification needs an external reference and, ideally, an external vantage point.

What to detect and where

ATT&CK v20 has three detection strategies. The data components and log sources are from v20; the last column is NHI Mgmt Group's practical guidance.

Verifying the image: Cisco IOS as a worked example

Cisco's IOS Software Integrity Assurance guidance gives a concrete verification set. Other vendors have equivalents; check your platform's documentation.

For appliances with vendor integrity tools (for example the Ivanti Integrity Checker Tool), run both the internal and the external scan, and compare the number of steps reported with a known-good run, as Google's analysis advises. The Ivanti Connect Secure Hardening and Integrity Checking Guide covers that platform. Treat unexpected reboots and gaps in logging as signals: Cisco Talos gives that advice for ArcaneDoor, where an implant suppressed crash dumps to avoid forensic analysis.

Mitigations

Two more controls matter for downgrades: maintain an approved version list per platform and alert on any device reporting a version not on it, and restrict image transfer protocols (TFTP and FTP) to a management network with logging. Cisco notes that signed images would not have stopped its in-memory incidents, so combine signing with memory checks and AAA restrictions on debug commands.

Where identity fits

A modified appliance image is a credential collection point. DRYHOOK captured user passwords at sign-in, and the 2024 Ivanti case exposed stored service account credentials, API keys and certificates. If an image is confirmed modified, treat everything the device stored or saw as exposed: directory bind accounts, RADIUS and TACACS+ shared secrets, SNMP strings, VPN certificates and their private keys, API tokens for management platforms and the passwords of every user who signed in during the window. Rotate them after the device is rebuilt from known-good media, not before, or the new secrets will be captured too. The Edge Device Compromise Investigation Playbook covers sequencing.

How to test

1. Inventory: for each device class, record the approved image name, version and vendor hash.
2. Automate storage checks: schedule hash and signature verification and send results to the SIEM; confirm a mismatched test file in a lab raises an alert.
3. Exercise the CLI rules: in a lab, copy an image and change the boot variable; confirm the DET0170 and DET0569 style rules fire from both syslog and AAA accounting.
4. Memory checks: on a lab unit of the same model, confirm the vendor-supported memory verification works without reloading the platform before using it in production.
5. Roll back: restore the approved boot variable and image, reverify the hash and signature, and record the test.

Metrics:

• Percentage of network devices with image hash and signature verified in the last 30 days.
• Percentage of devices on hardware that supports secure boot with it enabled.
• Number of devices running a version not on the approved list.
• Percentage of image copy and boot commands with a matching change record.
• Time to rebuild a device from known-good media and rotate its stored secrets in an exercise.

Common failure patterns

• Relying on the device to check itself. The Ivanti cases show an on-box checker can be evaded; compare against vendor hashes from outside.
• Checking only the file on flash. In-memory patching leaves the stored image clean.
• Accepting any signed image. A genuine old image passes signature checks, which is why downgrade detection needs an approved version list.
• Rebooting a suspect device first. Reloading destroys in-memory evidence; Talos advises not rebooting or collecting a core dump when ArcaneDoor compromise is suspected, and following vendor forensic steps instead.
• Rotating secrets before rebuilding. New credentials pass through the still-modified image.

Framework mapping

Practitioner checklist

• Keep an approved image list with vendor hashes for every network platform.
• Verify stored image hashes and signatures on a schedule and on every copy and reload.
• Enable secure boot and signed image enforcement where the hardware supports it.
• Alert on image copies, boot variable changes and unplanned reloads.
• Restrict debug, test and boot commands through AAA command authorisation and record them with accounting.
• Alert on any device reporting a version not on the approved list.
• Prepare a vendor-specific memory verification procedure tested on lab hardware.
• Document which secrets each appliance stores, and rotate them after a known-good rebuild.

Standards and references

• MITRE ATT&CK: T1601 Modify System Image
• MITRE ATT&CK: T1601.001 Patch System Image
• MITRE ATT&CK: T1601.002 Downgrade System Image
• Cisco: IOS Software Integrity Assurance
• Cisco: Evolution of attacks on Cisco IOS devices
• Google Cloud Threat Intelligence: Ivanti Connect Secure VPN targeted in new zero-day exploitation
• Cisco Talos: ArcaneDoor, espionage campaign targeting perimeter network devices

Related NHI Mgmt Group resources: ATT&CK Stealth and Defense Impairment Tactics Guide · Edge Device Security Guide · Firmware and Boot Security Guide · Vulnerability Management for Network Devices Guide · Cisco IOS XE Hardening Guide