Applied Cybernetics Group
T1601 Modify System Image
- Technique
T1601- Tactics
- Defense Evasion
- Research, 90 days
- 0
- KEV CVEs mapped
- 1
- SigmaHQ rules
- 0
- Elastic, Splunk
- 1
- thrunt rules
- 0
- Upstream
- https://attack.mitre.org/techniques/T1601
MITRE description
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.(Citation: Cisco Networking Software Product Lines)(Citation: Network Device Integrity Methodology) 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.
KEV CVEs mapped to this technique
MITRE CTID maps these KEV CVEs to this technique by hand. They are the actively exploited vulnerabilities behind this technique's KEV signal.
Detection coverage
malicious image install is command-identical to a routine upgrade; the discriminator (image hash/signature) is not present in standard syslog as a single event
Modify System Image is the Synful Knock lineage: trojanized IOS or FortiOS images installed through the device's own upgrade machinery: and the KEV signal here (CVE-2021-44168, a FortiOS arbitrary-file-write) fits that pattern. The problem for base Sigma is that the malicious command stream is byte-for-byte a routine upgrade: 'copy tftp: flash:', 'boot system flash:<image>', 'reload'. An AAA-command rule keyed on those strings fires on every legitimate change-window upgrade, which fails our own precedent that a rule firing on routine admin activity is worse than a documented hold. The actual discriminator is the image hash or signature, and standard device syslog does not carry it as a matchable single event; platforms with secure boot do emit image-validation-failure messages, but the message IDs vary across platform and software train and no SigmaHQ cisco syslog field convention exists for them: a keyword rule over unstable message IDs would be fragile and untestable. The part of this problem a rule can cover (pointing the boot source at an attacker-controlled network server) is covered by the T1542.005 rule we authored in this batch. Compensating controls for the rest: scheduled 'verify /md5' checks against vendor-published hashes, secure-boot/Trust Anchor capable platforms, image-inventory drift monitoring against a golden-image list, and out-of-band config/image archives.
Compensating controls
- Scheduled 'verify /md5' (or platform equivalent) against vendor-published image hashes, tracked as an ops control
- Prefer secure-boot / Trust Anchor capable platforms where image signature enforcement is hardware-backed
- Golden-image inventory and drift monitoring (NMS-side comparison of running image name/version/hash per device)
- Out-of-band config and image archives to make post-incident diffing possible
- thrunt T1542.005 rule for the boot-from-TFTP corner of image tampering
Revisit when: SigmaHQ establishing a cisco or fortinet syslog convention for image-integrity/secure-boot violation messages (stable message-ID fields), or the corpus surfacing a specific family with a stable install-time observable, a fixed implant image filename or boot string, that would support a family-scoped rule.
Elastic and Splunk rules
- Kernel Load or Unload via Kexec Detected (elastic)