Detect Downgrade System Image in Splunk
Adversaries may install an older version of the operating system of a network device to weaken its security posture. Older OS versions on network devices (Cisco IOS, Juniper JunOS, Palo Alto PAN-OS, Fortinet FortiOS) frequently have weaker encryption ciphers, unpatched vulnerabilities, and absent defensive features. On embedded devices, a downgrade typically requires replacing the OS image in flash storage and reconfiguring the boot system directive to point to the older file. The adversary downloads the target older image via TFTP, FTP, or SCP, overwrites or places it alongside the current image, and issues a 'boot system' change — either triggering an immediate reload or waiting for the next scheduled maintenance window. Downgrading enables follow-on techniques such as Weaken Encryption (T1600) and may be combined with Patch System Image (T1601.001) to install a backdoored older version. The SYNful Knock implant and Cisco IOS router compromise campaigns demonstrate this technique in real-world operations.
MITRE ATT&CK
- Tactic
- Defense Evasion
- Technique
- T1601 Modify System Image
- Sub-technique
- T1601.002 Downgrade System Image
- Canonical reference
- https://attack.mitre.org/techniques/T1601/002/
SPL Detection Query
index=syslog (sourcetype="syslog" OR sourcetype="cisco:ios" OR sourcetype="cisco:asa" OR sourcetype="juniper" OR sourcetype="paloalto:firewall" OR sourcetype="fortinet:fortigate")
| eval msg=lower(_raw)
| eval ImageTransfer=if(match(msg, "copy\s+(tftp|ftp|scp|http|https).*bootflash:|copy\s+(tftp|ftp|scp|http|https).*flash:|copy\s+(tftp|ftp|scp|http|https).*disk0:"), 1, 0)
| eval BootSystemChange=if(match(msg, "boot\s+system\s+(flash|bootflash|tftp|disk0|bootdisk).*\.(bin|tar|pkg|ova|qcow2)"), 1, 0)
| eval NoBootSystem=if(match(msg, "no\s+boot\s+system"), 1, 0)
| eval ReloadScheduled=if(match(msg, "reload\s+(in|at)\s+[0-9]"), 1, 0)
| eval InstallOp=if(match(msg, "(install\s+add|install\s+activate|archive\s+download|request\s+system\s+software|request\s+system\s+reboot|set\s+system\s+image)"), 1, 0)
| eval RollbackOp=if(match(msg, "(rollback|downgrade|previous.*version|older.*image|install\s+rollback)"), 1, 0)
| eval SuspicionScore=ImageTransfer*3 + BootSystemChange*3 + NoBootSystem*2 + ReloadScheduled*1 + InstallOp*2 + RollbackOp*3
| where SuspicionScore > 0
| eval VendorHint=case(
match(msg, "ios-xe|iosxe|catalyst|asr|isr"), "Cisco IOS-XE",
match(msg, "junos|juniper|mx-|ex-|qfx|srx"), "Juniper JunOS",
match(msg, "panos|pan-os|panorama"), "Palo Alto PAN-OS",
match(msg, "fortios|fortigate|fortiswitch"), "Fortinet FortiOS",
match(msg, "nxos|nexus|n9k|n7k"), "Cisco NX-OS",
1==1, "Unknown"
)
| table _time, host, sourcetype, VendorHint, _raw, ImageTransfer, BootSystemChange, NoBootSystem, ReloadScheduled, InstallOp, RollbackOp, SuspicionScore
| sort - SuspicionScore, - _timeDetects network device OS image downgrade attempts using syslog data in Splunk. Ingests from multiple vendor-specific sourcetypes (Cisco IOS, Juniper, Palo Alto, Fortinet) and the generic syslog sourcetype. Evaluates raw log messages against six risk categories: image transfer commands to flash storage, boot system directive changes, no-boot-system deletions, scheduled reloads, install/activate operations, and explicit rollback/downgrade references. Assigns a cumulative suspicion score with rollback and image transfer operations weighted highest (3 points). Includes vendor classification to aid routing to the appropriate network engineering team.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Authorized OS upgrade cycles where images are pre-staged to flash before a maintenance window cutover — the copy and boot system commands are expected.
- Automated network lifecycle management platforms (Cisco DNA Center, Ansible AWX, SolarWinds NCM) executing planned image deployments.
- Authorized rollback to a previous stable image after a failed upgrade during a maintenance window, documented in change management.
- Lab/test devices where engineers iterate through multiple image versions for compatibility or QA testing.
- ISSU (In-Service Software Upgrade) procedures on high-availability platforms where install add/activate sequences are part of normal non-disruptive upgrade workflows.
Other platforms for T1601.002
Testing Methodology
Validate this detection against 5 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate Image Transfer to Flash (Cisco IOS — TFTP Copy Command)
Expected signal: Syslog message containing 'copy tftp' and 'flash:' forwarded to the collector. Message format: '%SYS-5-CONFIG_I: Configured from console by <user> on <interface>' followed by copy initiation message. The SIEM should receive log entries matching the image transfer pattern within 30 seconds of command execution.
- Test 2Simulate Boot System Directive Change to Older Image
Expected signal: Syslog %SYS-5-CONFIG_I message indicating configuration change via console or vty. The boot system command itself may appear in TACACS+ accounting logs. On devices with enhanced logging: 'PARSER-5-CFGLOG_LOGGEDCMD: User logged command stem boot system flash:c7200-advipservicesk9-mz.122-55.bin'.
- Test 3Simulate Reload Scheduling After Image Staging (Cisco IOS)
Expected signal: Syslog message: '%SYS-5-RELOAD: Reload requested by <user> on <line>. Reload Reason: Reload Command.' followed by '%SYS-5-RELOAD_CANCEL: <user> cancel reload process'. Both messages are forwarded to the SIEM and should be visible within seconds.
- Test 4Verify Image Integrity Baseline (Cisco IOS — MD5 Hash Check)
Expected signal: The 'verify /md5' command generates a syslog message on completion: '%SYS-5-CONFIG_I' may appear if run from privilege exec, or a direct console output showing the computed hash. No network events are generated by the hash verification itself. The hash output is captured in the terminal session/TACACS+ accounting log.
- Test 5Juniper JunOS — Request System Software Downgrade Simulation
Expected signal: Juniper syslog message: 'UI_CMDLINE_READ_LINE: User <user>, Command request system software add ...' (from JUNOS SYSLOG). On Junos devices, all CLI commands are logged to syslog when command logging is enabled. The message will contain 'request system software' matching the InstallOp detection pattern.
References (9)
- https://attack.mitre.org/techniques/T1601/002/
- https://blogs.cisco.com/security/evolution-of-attacks-on-cisco-ios-devices
- https://tools.cisco.com/security/center/resources/integrity_assurance.html
- https://www.cisco.com/c/en/us/about/security-center/ios-integrity-assurance.html
- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1601.002/T1601.002.md
- https://www.mandiant.com/resources/synful-knock-acis
- https://learn.microsoft.com/en-us/azure/sentinel/connect-syslog
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/security/d1/sec-d1-xe-3se-3850-cr-book/sec-d1-xe-3se-3850-cr-book_chapter_011.html
- https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/command/request-system-software-add.html
Unlock Pro Content
Get the full detection package for T1601.002 including response playbook, investigation guide, and atomic red team tests.