Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1542.004: ROMMONkit

Adversaries may abuse the ROM Monitor (ROMMON) by loading an unauthorized firmware with adversary code to provide persistent access and manipulate device behavior that is difficult to detect. [1][2]

ROMMON is a Cisco network device firmware that functions as a boot loader, boot image, or boot helper to initialize hardware and software when the platform is powered on or reset. Similar to TFTP Boot, an adversary may upgrade the ROMMON image locally or remotely (for example, through TFTP) with adversary code and restart the device in order to overwrite the existing ROMMON image. This provides adversaries with the means to update the ROMMON to gain persistence on a system in a way that may be difficult to detect.

EnterpriseT1542.004Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

ROMMONkit matters because it targets the boot-level firmware of Cisco network devices, below normal operating visibility. If an attacker can place unauthorized code in ROMMON and cause the device to restart, persistence may survive normal configuration review and can affect how critical routing or network infrastructure behaves. For leaders, this is less about routine endpoint malware and more about whether network device lifecycle, firmware integrity, and audit practices are strong enough to support operational resilience.

Executive priority

Prioritize this where Cisco network devices support critical connectivity, regulated environments, or cyber-physical operations. Key leadership questions: do we know which network devices are legacy or hard to validate, do we control and audit firmware/boot changes, and can incident responders prove device boot integrity after a suspected compromise? Budget and compliance evidence should emphasize firmware governance, network-boundary monitoring, and repeatable audit of device images and change history.

Technical view

This is a Network Devices sub-technique under Pre-OS Boot with stealth and persistence tactics. SOC and IR teams should validate whether they can observe unauthorized ROMMON or boot image changes, suspicious firmware update activity, device restarts associated with image changes, and remote transfer paths such as TFTP where present. Because ATT&CK provides no official detection text, detection engineering should lean on the related DET0175 strategy, local device logging, configuration/image baselines, network transfer telemetry, and audit evidence rather than assuming standard OS or EDR controls apply.

Likely telemetry

  • Network device system and boot logs
  • Firmware, ROMMON, and boot image version/integrity records
  • Configuration change and administrative command audit logs
  • Device restart/reload events
  • Network transfer telemetry involving firmware/image movement, including TFTP where used

Detection direction

  • Validate DET0175-aligned coverage for ROMMONkit rather than relying on generic endpoint detections.
  • Baseline approved ROMMON, boot image, and firmware versions for network devices and alert on unauthorized drift.
  • Correlate image or firmware change events with administrative identity, change tickets, transfer activity, and device reloads.
  • Tune for legitimate maintenance windows and approved firmware upgrades to reduce false positives.
  • Assess blind spots around legacy devices, weak device logging, missing network-transfer visibility, and lack of historical firmware baselines.

Mitigation priorities

  • Apply Boot Integrity controls where supported to verify the integrity of the boot process and associated firmware components.
  • Implement regular auditing of network device activity, configurations, firmware versions, and boot-related changes.
  • Use network intrusion prevention or detection signatures at network boundaries to help block or identify suspicious traffic related to unauthorized image movement.
  • Strengthen change control for network device firmware and ROMMON updates, including approval, verification, and post-change validation.
  • Prioritize review of legacy network devices because the supplied references emphasize continued targeting of legacy devices.
Analyst notes and limits

The supplied ATT&CK object is specific to Cisco ROMMON on network devices and is associated with stealth and persistence. It is a sub-technique of Pre-OS Boot, so the defensive value is in validating the device boot chain and firmware state. The external references are Cisco publications, and the relationship context provides one detection strategy and three mitigations: Network Intrusion Prevention, Boot Integrity, and Audit.

MITRE does not provide official detection text for this object in the supplied fields. The record does not establish active exploitation, specific affected product versions, or guaranteed detection logic. Local device models, firmware capabilities, logging configuration, administrative practices, and network architecture are required to determine actual exposure and coverage.

Official MITRE ATT&CK definition

ROMMONkit

Adversaries may abuse the ROM Monitor (ROMMON) by loading an unauthorized firmware with adversary code to provide persistent access and manipulate device behavior that is difficult to detect. [1][2]

ROMMON is a Cisco network device firmware that functions as a boot loader, boot image, or boot helper to initialize hardware and software when the platform is powered on or reset. Similar to TFTP Boot, an adversary may upgrade the ROMMON image locally or remotely (for example, through TFTP) with adversary code and restart the device in order to overwrite the existing ROMMON image. This provides adversaries with the means to update the ROMMON to gain persistence on a system in a way that may be difficult to detect.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1542 Pre-OS Boot This object subtechnique of Pre-OS Boot.
Relationship explorer

All related ATT&CK context

mitigates · Mitigation M1046: Boot Integrity Enterprise detects · Detection Strategy DET0175: Detection Strategy for T1542.004 Pre-OS Boot: ROMMONkit Enterprise mitigates · Mitigation M1047: Audit Enterprise subtechnique of · Technique T1542: Pre-OS Boot Enterprise mitigates · Mitigation M1031: Network Intrusion Prevention Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1046: Boot Integrity

Boot Integrity ensures that a system starts securely by verifying the integrity of its boot process, operating system, and associated components. This mitigation focuses on leveraging secure boot mechanisms, hardware-rooted trust, and runtime integrity checks to prevent tampering during the boot sequence. It is designed to thwart adversaries attempting to modify system firmware, bootloaders, or critical OS components. This mitigation can be implemented through the following measures:

Implementation of Secure Boot:

- Implementation: Enable UEFI Secure Boot on all systems and configure it to allow only signed bootloaders and operating systems. - Use Case: An adversary attempts to replace the system’s bootloader with a malicious version to gain persistence. Secure Boot prevents the untrusted bootloader from executing, halting the attack.

Utilization of TPMs:

- Implementation: Configure systems to use TPM-based attestation for boot integrity, ensuring that any modification to the firmware, bootloader, or OS is detected. - Use Case: A compromised firmware component alters the boot sequence. The TPM detects the change and triggers an alert, allowing the organization to respond before further damage.

Enable Bootloader Passwords:

- Implementation: Protect BIOS/UEFI settings with a strong password and limit physical access to devices. - Use Case: An attacker with physical access attempts to disable Secure Boot or modify the boot sequence. The password prevents unauthorized changes.

Runtime Integrity Monitoring:

- Implementation: Deploy solutions to verify the integrity of critical files and processes after boot. - Use Case: A malware infection modifies kernel modules post-boot. Runtime integrity monitoring detects the modification and prevents the malicious module from loading.

Mitigation Enterprise

M1047: Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements. The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures.

Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.This mitigation can be implemented through the following measures:

System Audit:

- Use Case: Regularly assess system configurations to ensure compliance with organizational security policies. - Implementation: Use tools to scan for deviations from established benchmarks.

Permission Audits:

- Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation. - Implementation: Run access reviews to identify users or groups with excessive permissions.

Software Audits:

- Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector. - Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.

Configuration Audits:

- Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA). - Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.

Network Audits:

- Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections. - Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
41cc3afd43dc9764...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 41cc3afd43dc…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Cisco Synful Knock Evolution

    Graham Holmes. (2015, October 8). Evolution of attacks on Cisco IOS devices. Retrieved October 19, 2020.

    Open source URL
  2. [2]
    Cisco Blog Legacy Device Attacks

    Omar Santos. (2020, October 19). Attackers Continue to Target Legacy Devices. Retrieved October 20, 2020.

    Open source URL
  3. [3]
    mitre-attack T1542.004
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use