T0873: Project File Infection
Adversaries may attempt to infect project files with malicious code. These project files may consist of objects, program organization units, variables such as tags, documentation, and other configurations needed for PLC programs to function.[1] Using built in functions of the engineering software, adversaries may be able to download an infected program to a PLC in the operating environment enabling further Execution and Persistence techniques.[2]
Adversaries may export their own code into project files with conditions to execute at specific intervals.[3] Malicious programs allow adversaries control of all aspects of the process enabled by the PLC. Once the project file is downloaded to a PLC the workstation device may be disconnected with the infected project file still executing.[2]
Analyst context for executives and security teams
Project File Infection matters because PLC project files can become a trusted delivery path for malicious logic. In practice, the risk is not just a compromised engineering workstation file; it is that infected control logic may be downloaded through normal engineering software functions and continue executing on a PLC even after the workstation is disconnected. For leaders, this makes project-file integrity, change approval, and recoverable known-good baselines essential to operational resilience in ICS environments.
Executive priority
Prioritize this as an engineering-change governance and cyber-physical resilience issue. The business question is whether the organization can prove that PLC project files, downloads, and configuration changes are authorized, intact, and recoverable from known-good states. Budget and audit focus should favor file and directory permission controls, encryption of sensitive project data at rest, code-signing or integrity verification where supported, and periodic audits/integrity checks after reboots, downloads, or restarts.
Technical view
SOC, detection engineering, and IR teams should validate monitoring around engineering workstations and PLC project repositories, especially where project files contain objects, program organization units, tags, documentation, and PLC configurations. ATT&CK provides no official detection text for T0873, but the relationship to DET0766 indicates a dedicated detection strategy exists. Defensive validation should focus on unauthorized or unexpected project file modifications, movement of project files into the environment, project downloads to PLCs, and integrity comparison against known-valid project/program states. The related Siemens Project File Format sub-technique indicates vendor-specific project formats may require tailored parsing and baselining.
Likely telemetry
- Engineering workstation file-system activity for PLC project directories and repositories
- Access control and permission changes on project files and directories
- Engineering software activity related to project export, import, build, and download functions
- PLC program download, restart, or program-change records where available
- Cryptographic hashes, digital signatures, or other integrity baselines for known-valid project files, programs, and configurations
Detection direction
- Confirm whether DET0766-aligned logic is implemented or whether project-file monitoring is only assumed through generic endpoint logging.
- Baseline known-good project files and alert on unauthorized changes, especially before or after PLC downloads, restarts, or reboots.
- Tune detections with engineering-change windows and approved maintenance activity to reduce false positives while preserving evidence of who changed what, when, and from where.
- Account for blind spots where engineering software stores logic in proprietary or vendor-specific formats, including the related Siemens project-file sub-technique.
- Validate coverage on the related Workstation asset class; ATT&CK lists workstations as Linux and Windows, but the parent technique itself does not specify platforms.
Mitigation priorities
- Restrict file and directory permissions for project repositories and engineering workstations so access is limited to authorized roles and accounts.
- Encrypt sensitive project information at rest where supported to reduce exposure of control logic and configuration content.
- Use code signing or digital signature verification where available to prevent untrusted code or application content from being accepted as legitimate.
- Perform periodic audits and integrity checks of systems, permissions, software, programs, and configurations, comparing results to known-valid states after downloads, reboots, or restarts.
- Maintain recoverable, known-good PLC project baselines and include project-file integrity checks in incident response and change-management procedures.
Analyst notes and limits
This technique is especially material because normal engineering workflows may be used to transfer infected logic into the operating environment. The relationship set supports a practical defensive program centered on permissions, encryption, code signing, audits, and integrity validation. The related target asset is the engineering/operator workstation, and the related sub-technique highlights Siemens project-file formats as a more specific case.
The supplied ATT&CK object does not specify tactics or platforms and provides no official detection text. Any detection coverage, vendor-specific parser, PLC telemetry source, or environmental exposure assessment must be validated against local engineering tools, asset inventory, project-file formats, and change-management records.
Project File Infection
Adversaries may attempt to infect project files with malicious code. These project files may consist of objects, program organization units, variables such as tags, documentation, and other configurations needed for PLC programs to function.[1] Using built in functions of the engineering software, adversaries may be able to download an infected program to a PLC in the operating environment enabling further Execution and Persistence techniques.[2]
Adversaries may export their own code into project files with conditions to execute at specific intervals.[3] Malicious programs allow adversaries control of all aspects of the process enabled by the PLC. Once the project file is downloaded to a PLC the workstation device may be disconnected with the infected project file still executing.[2]
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 |
|---|---|---|---|
| ICS | T0873.001 | Siemens Project File Format Sub-technique | Siemens Project File Format subtechnique of this object. |
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 | 1.1 | Current bundle | f08404ae0dc0… |
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]
Beckhoff
Beckhoff TwinCAT 3 Source Control: Project Files Retrieved. 2019/11/21
Open source URL -
[2]
PLCdev
PLCdev Nicolas Falliere, Liam O Murchu, Eric Chien 2011, February W32.Stuxnet Dossier (Version 1.4) Retrieved. 2017/09/22 Siemens SIMATIC Step 7 Programmer's Handbook Retrieved. 2019/11/21
Open source URL -
[3]
Nicolas Falliere, Liam O Murchu, Eric Chien February 2011
Nicolas Falliere, Liam O Murchu, Eric Chien 2011, February W32.Stuxnet Dossier (Version 1.4) Retrieved November 17, 2024.
Open source URL -
[4]
mitre-attack T0873Open 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.