Detecting and Mitigating Modified Network Device Images (T1601)

Modify System Image (T1601) is listed under the Defense Impairment tactic in MITRE ATT&CK, for the Network Devices platform. The adversary changes the operating system of an embedded network device, to weaken its defenses or to give themselves new capabilities.

Servers have layers: a bootloader, an operating system, packages, applications. Many embedded network devices do not. The whole device is, effectively, one file. That makes the file a high-value target and makes verifying it a high-value habit.

How attackers use it

MITRE says operating systems on such devices are typically monolithic, with most functionality contained in a single file. To change the operating system, an adversary typically only needs to affect that one file, by replacing or modifying it.

The change can happen in two places:

• Live in memory, while the device runs, for immediate effect.
• In storage, to take effect on the next boot.

The sub-techniques show what the change is for:

• Patch System Image (T1601.001), which modifies the image to add capabilities or weaken defenses.
• Downgrade System Image (T1601.002), which installs an older version with weaker defenses.

Other MITRE techniques show what a modified image can be used for. A changed image can impair encryption (Weaken Encryption, T1600), authentication, and perimeter defenses (Network Boundary Bridging, T1599). Because the device's own software has been altered, anything the device reports about itself, such as version output, may not be trustworthy.

That last point is the reason independent checks matter. If the thing you ask for the truth has been modified, ask something else too.

How to detect it

MITRE's detection strategy covers several kinds of evidence:

• Anomalous CLI commands.
• Unexpected firmware updates.
• Integrity check failures.
• Mismatches in version and checksum validation.
• Modification of image files in storage.
• OS version output that does not match your baselines.
• Unexpected reloads or reboots after an image is replaced.
• Changes to boot configuration that load a non-standard image.

Turn that into controls you can run:

1. Keep an inventory of each device's approved image name, version and hash.
2. Compare the running and stored images with that inventory on a schedule, and after every reboot.
3. Log administrative sessions and CLI commands to a central system the device cannot alter.
4. Alert on reloads that are not part of an approved change.
5. Watch for transfer of image-sized files to or from the device by TFTP, FTP or SCP.

The data sources that make this work are device configuration and command logs, file monitoring where the platform offers it, and network flow records of file transfers to the management plane.

How to reduce the risk

MITRE lists these mitigations.

1. Multi-factor Authentication. Use it for user and privileged accounts. Most embedded network devices support TACACS+ or RADIUS, and vendor best practices for hardening access control apply.
2. Password Policies. Follow NIST guidance.
3. Credential Access Protection. Some devices store local passwords in plain text or encrypted form. Make sure, where available, that local passwords are always encrypted, per vendor recommendations.
4. Code Signing. Many vendors provide digitally signed operating system images so the integrity of the platform software can be validated. Use that where possible to prevent or detect attempts to compromise the image.
5. Boot Integrity. Some vendors cryptographically sign images to verify integrity at boot. Implement it where available, following vendor guidance.

The common thread is trust in the image. Signed images and secure boot make a modified file fail to load. Strong authentication makes it harder to place the file at all.

Check your own environment

On a Cisco IOS or IOS XE device (read-only; syntax varies by platform and software release, so confirm against your vendor documentation):

show version
show boot

Where supported, on IOS XE you can also check the signature of the running image:

show software authenticity running

You can compute a hash of an image stored in flash and compare it with the vendor's published value (the file name here is an example):

verify /md5 flash:your-image.bin

Then review:

• Do you have a written list of approved images per device, with hashes?
• Is secure boot or signed image checking enabled where your hardware supports it?
• Who can copy files to a device, and is that tied to a change ticket?
• Do device logs go to a collector the device cannot erase?

Try it yourself

Verifying that what is running matches what was built is the idea behind attestation and provenance. This demo shows it for software artifacts.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MITRE ATT&CK, Modify System Image (T1601)