Program Upload (T0845) is an adversary reading the program out of a PLC so they can study the logic that runs the physical process. Upload is a normal engineering function: vendor software uses it to back up controllers, compare versions and troubleshoot. In an adversary's hands the same function gives them the control logic, tag names and process design they need to plan manipulation, and some intrusions have used it to take project files away. MITRE ATT&CK for ICS lists T0845 under Collection for the Embedded platform. Note the direction: upload moves the program from the controller to a workstation; the reverse, Program Download (T0843), writes a program to the controller. This guide is for control engineers, OT security engineers and OT SOC analysts. For the wider matrix see the MITRE ATT&CK for ICS Guide, and for controller hardening the PLC Security Guide.
Key takeaways
- Upload is a legitimate feature. ATT&CK notes that vendor software lets users upload and read a running program to a workstation, jump box or interfacing device, so the activity blends with backups.
- Real intrusions have used it. ATT&CK records CyberAv3ngers using program upload to take project files from victim PLCs, and INCONTROLLER uploading logic from Schneider and Omron PLCs.
- Who uploads, and when, is the signal. ATT&CK's v20 analytic alerts on a program readback to a source outside the approved engineering workstation list, outside the backup window.
- Controllers can restrict upload. ATT&CK's mitigations call for authentication on all management sessions and role-based control over who may upload.
- Upload is often a precursor. A stolen program lets an adversary plan modifications offline, so treat an unexplained upload as early warning of a later download.
What T0845 covers and why it matters in OT
ATT&CK for ICS describes T0845 as adversaries attempting to upload a program from a PLC to gather information about an industrial process, acquiring and studying the underlying logic. Methods include vendor software that can upload and read a program running on a PLC to a workstation, jump box or interfacing device.
| Question | Program Upload (T0845) | Program Download (T0843) |
|---|---|---|
| Direction | Controller to workstation | Workstation to controller |
| ATT&CK tactic | Collection | Lateral Movement |
| Immediate process effect | None expected; it is a read | Can change control behaviour |
| Why an adversary does it | Learn the logic, tags and set points; take project files | Run modified or malicious logic |
| Legitimate uses | Backups, version comparison, troubleshooting | Commissioning and approved changes |
The program often carries more than logic: tag names, comments and network settings describe the plant. That is why upload sits alongside Theft of Operational Information (T0882) in many threat models, and why it is worth detecting even though it changes nothing on the controller.
Procedure examples in ATT&CK
- CyberAv3ngers (G1027): during the 2026 Iranian Water Campaign, ATT&CK records the group using the program upload feature to exfiltrate project files from victim PLCs.
- INCONTROLLER (S1045): ATT&CK records that it can use the CODESYS protocol to upload programs from Schneider PLCs, and can obtain existing program logic from Omron PLCs through the program upload or backup functions of the HTTP server. CISA advisory AA22-103A describes the Omron component as able to back up and restore arbitrary files to and from the PLC.
- Triton (S1009): ATT&CK records Triton calling SafeAppendProgramMod to transfer its payloads to the safety controller, with part of that call performing a program upload. Safety instrumented systems need the strictest controls on who can reach their management functions.
Detection: ATT&CK v20 analytic
MITRE's v20 detection strategy for T0845 (DET0761) has one embedded analytic, with ATT&CK's OT operational fidelity gate: suppress approved backups, diagnostics and engineering work, and alert when the source is not authorised or the activity departs from the baseline.
| Element | What ATT&CK describes | How to build it |
|---|---|---|
| Network signal | An ICS protocol session reading back the user program from a field device to a source not on the approved engineering workstation list, with a byte count consistent with a substantial part of program memory; examples given are S7comm Upload Block and CIP program read sessions | OT network monitoring with protocol decoding at the controller zone conduit |
| Host signal | Engineering application audit or session log showing a controller program upload outside the approved backup or change window without a documented backup purpose | Forward engineering software logs where the product records upload events |
| Tunable inputs | Backup window schedule, engineering workstation list, program upload size threshold | Agree with control engineers; include automated backup servers on the list |
Two practical points. Automated backup tools upload programs on a schedule, so their source address and timing belong in the baseline. Controllers that log upload events or access attempts locally are worth collecting where the product supports it. See the OT Network Security Monitoring Guide.
Prevention: ATT&CK mitigations in practice
| Mitigation | ATT&CK guidance for T0845 | Practical application |
|---|---|---|
| M0800 Authorization Enforcement | Restrict program uploads to certain users, such as engineers and field technicians, preferably with role-based access | Use controller and project role settings where the product offers them |
| M0804 Human User Authentication | Require authentication for all remote or local management sessions | Turn on controller and project passwords; replace defaults |
| M0801 Access Management | Authenticate all access to field controllers; centralised authentication helps manage many accounts | Put an authenticating gateway or jump host in front of controllers that cannot authenticate users |
| M0813 Software Process and Device Authentication | Authenticate connections from software and devices to protect management functions | Use certificate or key based trust between engineering software and controllers where supported |
| M0802 Communication Authenticity | Device management protocols should authenticate all messages | Enable secure communication modes in newer controller firmware after testing |
| M0930, M0937, M0807 | Segment, filter program upload protocols and payloads, and use host-based allowlists so devices accept connections only from known management systems | Allow management protocol traffic to controllers only from named engineering workstations and backup servers |
CISA's AA22-103A recommendations reinforce this: limit ICS network connections to specifically allowed management and engineering workstations, change default passwords, and keep known-good offline backups with integrity checks of controller configurations. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Where identity fits
Upload controls depend on knowing who is connecting. Shared engineering passwords and controller passwords that integrators keep after a project end mean any of them can take the program. Use named engineering accounts, remove integrator access outside agreed windows, rotate controller and project passwords when staff or contractors leave, and treat the service account of an automated backup server as privileged, since it can read every controller. See the OT and ICS Identity and Access Guide and the OT Remote Access Guide.
How to implement
- List legitimate upload sources: engineering workstations, backup servers and integrator jump hosts, with schedules.
- Restrict reachability: allow controller management protocols only from those sources at the conduit, logging denies before enforcing.
- Deploy DET0761-style alerts in alert-only mode through a backup cycle, then promote to the OT SOC queue.
- Enable controller protections: passwords, project protection and role settings, first on a test or spare controller, with the previous settings recorded for rollback.
- Protect the copies: program backups and project files are as sensitive as the controller; store them with access control and integrity hashes. See the OT Backup, Recovery and Golden Image Guide.
Decision guidance
- Controllers with access control features: enable them; the cost is credential management, which a central approach reduces.
- Legacy controllers without authentication: rely on a single permitted engineering path, network allowlists and monitoring, and plan replacement.
- Small sites: conduit rules plus one hardened engineering workstation and protected backups remove most exposure.
- Large or safety-critical sites: add protocol-aware monitoring, engineering log collection and a separate, narrower path to safety controllers. See the Engineering Workstation Security Guide.
Responding to an unexplained upload
An upload does not change the process, so there is time to investigate without disturbing operations. Confirm with engineering whether it was planned. If not, preserve the network capture or session record, the source host's logs and the controller's own logs. Assume the program, its tags and any embedded network settings are now known to the adversary; review what that exposes. Investigate the source host and account, block its access to controllers at the conduit, and rotate controller and project passwords it could have used. Watch closely for a later download or mode change to the same controller. See the OT Incident Response Guide.
Detection and measurement
- Source coverage: percentage of controllers with a documented list of approved upload sources.
- Reachability: number of hosts able to reach controller management ports, against that list.
- Protection coverage: percentage of controllers with authentication or project protection enabled where supported.
- Unexplained uploads: count of upload sessions not matched to a backup schedule or change ticket.
- Backup integrity: percentage of program backups with stored hashes checked in the last quarter.
Framework mapping
| Framework | Reference | How it applies |
|---|---|---|
| MITRE ATT&CK for ICS v20 | T0845; M0800, M0801, M0802, M0804, M0807, M0813, M0930, M0937; DET0761; related T0843, T0882 | Technique, mitigations, analytic and related techniques |
| NIST SP 800-53 Rev. 5 | AC-3 Access Enforcement, IA-3 Device Identification and Authentication, AC-4 Information Flow Enforcement, SI-4 System Monitoring, CP-9 System Backup | Restricting who can read programs, network control, monitoring and protected backups |
| NIST CSF 2.0 | PR.AA-05, PR.IR-01, DE.CM-01, PR.DS-01 | Access permissions, network protection, monitoring and protecting stored programs |
Common failure patterns
- Controller passwords left off or default: anyone with network reach can read the program.
- Every host can reach every controller: a compromised office or HMI host can run vendor software against controllers.
- Backups stored openly: project files on shared drives give the same information without touching the controller.
- Upload treated as harmless: reads are never alerted, so preparation for a later attack goes unseen.
- Integrator access never removed: project credentials stay valid long after the work ends.
Practitioner checklist
- Document approved upload sources and backup schedules for each controller.
- Restrict controller management protocols to those sources at every conduit.
- Alert on program readback sessions from unapproved sources or outside backup windows.
- Enable controller authentication, role settings and project protection after testing.
- Store program backups with access control and integrity hashes.
- Treat backup server service accounts as privileged.
- Remove integrator access and rotate project passwords at the end of each engagement.
- After any unexplained upload, watch the same controller for download and mode changes.
Standards and references
- MITRE ATT&CK for ICS: Program Upload (T0845)
- MITRE ATT&CK: Detection of Program Upload (DET0761)
- MITRE ATT&CK: INCONTROLLER (S1045)
- MITRE ATT&CK: CyberAv3ngers (G1027)
- CISA and partners: AA22-103A, APT Cyber Tools Targeting ICS/SCADA Devices
- CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · PLC Security Guide · Engineering Workstation Security Guide · OT Backup, Recovery and Golden Image Guide