AN0777: Analytic 0777
Unexpected firmware image uploads via TFTP/FTP/SCP. Configuration changes modifying boot image pointers. Logs showing boot variable redirection to non-standard images. Anomalous reboots immediately following firmware changes not tied to patch schedules.
Analyst context for executives and security teams
This analytic matters because unauthorized or unexpected firmware image changes on network devices can put routing, switching, and remote connectivity at risk. For executives and security leaders, the key decision is whether the organization can prove that firmware uploads, boot image changes, and reboots are authorized, scheduled, and recoverable—not merely whether endpoints and servers are monitored.
Executive priority
Prioritize this where network devices support critical business connectivity, regulated environments, remote operations, or cyber-physical dependencies. Leaders should ask whether firmware change activity is governed by maintenance windows, whether evidence is retained for audit and incident response, and whether teams can quickly distinguish planned patching from suspicious image upload or boot redirection activity.
Technical view
This ATT&CK analytic is scoped to Network Devices and describes signs such as unexpected firmware image uploads over TFTP, FTP, or SCP; configuration changes that alter boot image pointers; logs showing boot variable redirection to non-standard images; and anomalous reboots immediately after firmware changes outside patch schedules. SOC and IR teams should validate that network device logs, configuration change records, file transfer records, and reboot events can be correlated against approved change windows and known firmware baselines.
Likely telemetry
- Network device system logs and audit logs
- Configuration change logs, especially boot variable or image pointer changes
- Firmware image upload records involving TFTP, FTP, or SCP
- Device reboot events and uptime changes
- Change management or maintenance window records
Detection direction
- Correlate firmware upload events with configuration changes that modify boot image references and subsequent reboots.
- Tune detections against approved patch schedules and maintenance windows to reduce false positives from legitimate firmware upgrades.
- Flag boot variables or image pointers that reference non-standard, unexpected, or unapproved firmware images.
- Validate visibility for TFTP, FTP, and SCP activity to and from network devices; gaps here can materially weaken coverage.
- Because no tactic or relationship context is supplied, treat this as behavior-focused monitoring rather than attribution- or campaign-specific detection.
Mitigation priorities
- Establish and enforce formal firmware change approval and maintenance windows for network devices.
- Maintain an inventory of approved firmware images and expected boot configurations.
- Restrict and monitor administrative file transfer methods used for firmware uploads, including TFTP, FTP, and SCP where present.
- Retain network device logs and configuration history long enough to support incident response and compliance evidence.
- Test recovery procedures for restoring known-good firmware and boot settings after unauthorized or erroneous changes.
Analyst notes and limits
The supplied object is a detection analytic, not a technique, and provides behavior indicators rather than a full detection logic. Its main value is as a validation checklist for network device firmware integrity monitoring, change governance, and IR readiness.
Official detection logic, tactics, relationships, attribution, and exploitation context were not provided. Local device types, logging capabilities, firmware management processes, and change-management data are required to assess practical coverage and risk.
Analytic 0777
Unexpected firmware image uploads via TFTP/FTP/SCP. Configuration changes modifying boot image pointers. Logs showing boot variable redirection to non-standard images. Anomalous reboots immediately following firmware changes not tied to patch schedules.
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 | 043447a31f80… |
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 AN0777Open 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.