AN1603: Analytic 1603
Detection of unauthorized changes to boot configurations pointing to TFTP servers, unusual firmware loads during netbooting, or suspicious TFTP traffic. Correlation of boot config modifications, command history logs, and unexpected system image hashes provides detection coverage for adversaries attempting to persist via malicious TFTP boot images.
Analyst context for executives and security teams
This analytic matters because network devices that boot from or load images through TFTP can become a persistence point if boot settings or firmware images are changed without authorization. For leaders, the practical issue is not just a device configuration change; it is whether the organization can prove that routers, switches, or similar network devices are booting trusted images and that suspicious TFTP activity would be noticed quickly.
Executive priority
Prioritize this where network devices are operationally critical or where device integrity is part of resilience, audit, or incident response evidence. Executives should ask whether teams can validate boot configuration changes, command history, TFTP traffic, and system image hashes for network devices. If those records are not collected or retained, incident responders may struggle to determine whether a device booted an unexpected image or whether a configuration change created a persistence risk.
Technical view
For SOC, detection engineering, and IR teams, validate visibility around network device boot configuration changes, command history logs, netboot behavior, TFTP traffic, and system image hash verification. The supplied ATT&CK object is a detection analytic for Network Devices and describes correlation of unauthorized boot configuration changes, unusual firmware loads during netbooting, suspicious TFTP traffic, and unexpected system image hashes. Because no ATT&CK tactic, relationship context, or formal detection logic is supplied, teams should treat this as detection coverage guidance rather than a ready-to-deploy rule.
Likely telemetry
- Network device configuration change logs, especially boot configuration changes
- Network device command history or administrative command logs
- TFTP traffic records involving network devices
- Netboot or firmware load events where available
- System image or firmware hash inventory and validation records
Detection direction
- Correlate boot configuration modifications with command history and approved change windows to reduce false positives from legitimate maintenance.
- Review TFTP traffic involving network devices for unexpected servers, timing, or volume, while accounting for authorized netboot or firmware workflows.
- Compare observed system image hashes against approved baselines before treating an image load as suspicious.
- Validate that logging survives device reloads and that logs are centralized; otherwise, local-only evidence may be lost during the event being investigated.
- Because official detection logic is not provided, build environment-specific analytics using known device inventory, approved TFTP servers, approved images, and normal maintenance patterns.
Mitigation priorities
- Establish and maintain approved baselines for network device boot configurations and system image hashes.
- Restrict and monitor administrative changes to network device boot settings using existing access control and change management processes.
- Limit TFTP usage to authorized operational needs and known infrastructure where feasible.
- Retain centralized network device logs and command history sufficient for incident reconstruction.
- Periodically validate that firmware and boot image management processes produce auditable evidence for security operations, incident response, and compliance reviews.
Analyst notes and limits
This take is based on ATT&CK analytic AN1603 for Network Devices. The object focuses on detecting unauthorized boot configuration changes pointing to TFTP servers, unusual firmware loads during netbooting, suspicious TFTP traffic, and unexpected system image hashes. There are no supplied relationships, aliases, tactics, or official detection logic, so local engineering must define thresholds, baselines, and approval context.
The supplied ATT&CK fields do not identify a tactic, specific adversary behavior relationship, detection data model, query logic, or affected vendor technologies. This summary therefore cannot claim complete coverage, active exploitation, attribution, or guaranteed detection. The value of the analytic depends on whether the environment actually collects network device configuration, command, TFTP, netboot, and image integrity telemetry.
Analytic 1603
Detection of unauthorized changes to boot configurations pointing to TFTP servers, unusual firmware loads during netbooting, or suspicious TFTP traffic. Correlation of boot config modifications, command history logs, and unexpected system image hashes provides detection coverage for adversaries attempting to persist via malicious TFTP boot images.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 1.0 | Current bundle | e08dbe61f073… |
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]
mitre-attack AN1603Open 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.