Safeguard
Application Security•

Detecting and Mitigating Patched Network Device Images (T1601.001)

Patching a device image in storage or in memory can add capabilities or disable defenses. What T1601.001 means and how to verify what your devices run.

Safeguard Security Team
4 min read

Patch System Image (T1601.001) is a sub-technique of Modify System Image, in the Defense Impairment tactic, for the Network Devices platform. An adversary modifies a device's operating system to add new capabilities or weaken existing defenses.

Some network devices use a monolithic design, where the whole operating system and most functionality sit in a single file. That one file can be changed in storage, to load on a later boot, or in memory while the device runs.

How attackers use it

MITRE describes two broad routes.

In storage. The adversary typically uses the standard procedures available to device operators. That can mean downloading a new file by protocols common on network devices, such as TFTP, FTP, SCP, or a console connection. The original file may be overwritten, or a new one may be written alongside it with the device reconfigured to boot the compromised image.

In memory. There are two methods:

  1. Using native debug commands in the original, unaltered running operating system that let the adversary modify the memory addresses holding the running OS. This typically requires administrative level access.
  2. Using the boot loader, the first software that loads at start and then launches the operating system. Malicious code previously implanted in the boot loader, MITRE names the ROMMONkit method, can directly manipulate running OS code in memory, which lets the adversary patch the live operating system during runtime.

What does the patch do? By changing the instructions in the image, adversaries may weaken defenses or add capabilities the device did not have. MITRE lists encryption (Weaken Encryption), authentication (Network Device Authentication) and perimeter defenses (Network Boundary Bridging) among the defenses that can be impeded.

A thing to hold on to: the legitimate way to update a device and the malicious way look similar. Both copy an image and change boot settings. The difference is authorization.

How to detect it

MITRE's detection strategy:

  • Monitor for anomalous file transfers of image files by TFTP, SCP or FTP.
  • Watch for unauthorized CLI commands that alter boot system variables.
  • Look for integrity check mismatches between the running image and a baseline.
  • Look for runtime memory manipulation attempts, which may appear as debug commands or boot loader manipulation that does not fit normal administration.

A suspicious sequence is: upload a new image, change boot parameters, then reload or reboot the device. Alert on that sequence if it appears without a change record.

Put it in practice:

  • Flow records for the management plane, so a large file copy to a device shows up.
  • Central logging of every administrative command.
  • A scheduled comparison of the running image hash with your baseline.
  • Alerts on reboots outside maintenance windows.

How to reduce the risk

MITRE lists:

  1. Boot Integrity. Use vendor cryptographic signing to ensure image integrity at boot, where available.
  2. Code Signing. Use vendor-signed images to validate the software and to prevent or detect compromise.
  3. Credential Access Protection. Make sure local passwords on the device are encrypted where supported.
  4. Privileged Account Management. Restrict administrators to as few people as possible and avoid credential overlap between network and non-network platforms.
  5. Multi-factor Authentication. Use it for user and privileged accounts through TACACS+ or RADIUS, following vendor hardening guidance.

Because in-memory methods need administrative access, access control is the practical front line. Limit who can reach the management interface, keep it off the public internet, and do not reuse credentials.

Check your own environment

On a Cisco IOS or IOS XE device (read-only; confirm syntax with vendor documentation for your platform):

show version
show boot

Compare the image name and version with your approved list. If your platform supports it, also use the vendor's image verification feature to compare hashes.

Then review:

  • Is there a record of every approved image for every device?
  • Are TFTP, FTP and SCP to devices allowed only from known management hosts?
  • Do you log and review all administrative commands?
  • Is the management interface reachable only from a management network?

Quick check

What is the difference between patching in storage and in memory?

In storage, the image file is replaced or a new one is added and the device is set to boot it. In memory, the running operating system is changed live, using debug commands or a compromised boot loader.

What sequence of events does MITRE call suspicious?

Uploading a new image, changing boot parameters, and then reloading the device.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.