T1542.005: TFTP Boot
Adversaries may abuse netbooting to load an unauthorized network device operating system from a Trivial File Transfer Protocol (TFTP) server. TFTP boot (netbooting) is commonly used by network administrators to load configuration-controlled network device images from a centralized management server. Netbooting is one option in the boot sequence and can be used to centralize, manage, and control device images.
Adversaries may manipulate the configuration on the network device specifying use of a malicious TFTP server, which may be used in conjunction with Modify System Image to load a modified image on device startup or reset. The unauthorized image allows adversaries to modify device configuration, add malicious capabilities to the device, and introduce backdoors to maintain control of the network device while minimizing detection through use of a standard functionality. This technique is similar to ROMMONkit and may result in the network device running a modified image. [1]
Analyst context for executives and security teams
TFTP Boot matters because it turns a normal network-device administration feature into a persistence and stealth risk. If an attacker can change a network device’s boot configuration, the device may load an unauthorized operating system image from a TFTP server during startup or reset. For leaders, the concern is not just device compromise; it is loss of trust in routing, switching, and network control infrastructure that business operations depend on.
Executive priority
Prioritize this where network devices use centralized image management or netbooting. The key business question is whether the organization can prove that only authorized administrators, approved boot settings, and trusted images are used on network devices. This technique supports persistence and stealth, so incident decisions should include whether a device can still be trusted after reboot and whether configuration/image integrity evidence is available for audit, recovery, and containment.
Technical view
For SOC, detection engineering, and IR teams, validate visibility around network-device boot configuration, startup/reset events, and TFTP use. ATT&CK provides no official detection text for this object, but a related detection strategy, DET0582, exists for T1542.005. Use the relationship context to drive local detection design: look for unauthorized changes that specify TFTP boot behavior, unexpected TFTP server references, and post-reboot image or configuration deviations. Investigations should also consider the relationship to Modify System Image and the parent Pre-OS Boot technique, because the defensive question is whether the device is running the intended image before the operating environment is trusted.
Likely telemetry
- Network device configuration change logs, especially boot variables or startup configuration changes
- Administrative authentication and privileged account activity on network devices
- TFTP traffic metadata involving network devices and management servers
- Approved network-device image inventory and hash/version records where available
- Device startup, reset, and boot event logs
Detection direction
- Confirm whether network-device configuration changes are centrally logged and retained with administrator identity and timestamps.
- Baseline authorized TFTP servers and expected device-to-management-server TFTP activity; tune for exceptions rather than generic TFTP presence alone.
- Correlate boot configuration changes with privileged account activity, reset/startup events, and subsequent image or configuration state.
- Review DET0582 if available in the local ATT&CK content set, but do not assume coverage without implemented data sources and tested analytics.
- Account for false positives from legitimate network administration, maintenance windows, image upgrades, and centralized device image management.
Mitigation priorities
- Restrict privileged access to network-device administration using privileged account management, least privilege, monitoring, and accountability.
- Harden operating and boot configuration so netbooting and related boot options are only enabled where there is a legitimate operational requirement.
- Limit network access to TFTP and device management resources to authorized systems only.
- Use network intrusion prevention or monitoring at relevant network boundaries to detect or block unauthorized TFTP-related activity where feasible.
- Apply boot integrity controls and image validation practices appropriate for network devices so unauthorized images are not trusted.
Analyst notes and limits
This is a Network Devices sub-technique of Pre-OS Boot with stealth and persistence tactics. The supplied ATT&CK object states that adversaries may manipulate network-device configuration to use a malicious TFTP server and potentially load a modified image at startup or reset. The most important local validation is whether network operations, IAM, and SOC teams can jointly prove control over privileged changes, boot settings, TFTP access, and approved device images.
The official ATT&CK detection field is not provided, and the related DET0582 detection strategy is named but not described in the supplied data. This take therefore gives conservative validation direction rather than claiming specific detection logic or coverage. Local device models, logging capability, netboot usage, and management architecture are required to assess actual exposure and monitoring quality.
TFTP Boot
Adversaries may abuse netbooting to load an unauthorized network device operating system from a Trivial File Transfer Protocol (TFTP) server. TFTP boot (netbooting) is commonly used by network administrators to load configuration-controlled network device images from a centralized management server. Netbooting is one option in the boot sequence and can be used to centralize, manage, and control device images.
Adversaries may manipulate the configuration on the network device specifying use of a malicious TFTP server, which may be used in conjunction with Modify System Image to load a modified image on device startup or reset. The unauthorized image allows adversaries to modify device configuration, add malicious capabilities to the device, and introduce backdoors to maintain control of the network device while minimizing detection through use of a standard functionality. This technique is similar to ROMMONkit and may result in the network device running a modified image. [1]
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.
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1542 | Pre-OS Boot | This object subtechnique of Pre-OS Boot. |
All related ATT&CK context
Mitigation direction
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | 2d0a5e0cbbb3… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Cisco Blog Legacy Device Attacks
Omar Santos. (2020, October 19). Attackers Continue to Target Legacy Devices. Retrieved October 20, 2020.
Open source URL -
[2]
mitre-attack T1542.005Open source URL
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.