T0873 Project File Infection: Detecting Infected PLC Project Files

Project File Infection (T0873) is an adversary planting malicious code in the engineering project files that hold a PLC's logic, tags and configuration, so that the next legitimate download carries it into the controller. The engineer does the attacker's work: they open a trusted project, compile it and download it, and the infected program then runs in the controller even after the workstation is disconnected. MITRE ATT&CK for ICS v20 lists T0873 under Persistence for Windows and Linux, with one sub-technique, Siemens Project File Format (T0873.001), added in 2026. This guide is for control system engineers, OT security engineers and OT SOC analysts: how Stuxnet used project files, what ATT&CK's analytics look for, and how to make the integrity of engineering files something you can prove. Wider workstation hardening is in the Engineering Workstation Security Guide; this page goes deeper on the project files themselves.

Key takeaways

• Project files are code. ATT&CK describes them as holding objects, program organisation units, tag variables, documentation and configuration, and the engineering software turns them into what runs in the PLC.
• Stuxnet is the reference case. Symantec's dossier describes Stuxnet copying itself into Step 7 and WinCC project folders so its code ran when an engineer opened the project.
• Integrity is provable. ATT&CK's M0947 Audit says to verify a cryptographic hash of each project file against a known trusted version.
• Who writes the file matters. ATT&CK's Windows analytic alerts on writes to project files by any process other than the recognised engineering software, or by that software just after loading a file from an untrusted source.
• Keep signing keys elsewhere. M0945 Code Signing says to sign project files at rest and not to keep the signing keys on the same system.

What T0873 covers

ATT&CK for ICS describes adversaries infecting project files with malicious code, using built-in functions of the engineering software to download an infected program to a PLC and gain further Execution and Persistence. Adversaries may export their own code into project files with conditions to execute at specific intervals, and once the program is downloaded the workstation can be disconnected with the infected program still executing. The sub-technique T0873.001 adds that for Siemens project files (Step 7, WinCC and similar) the adversary may modify an existing project or bring their own, and needs a workstation with the Siemens programming software installed to perform the download.

Each of those techniques has its own page; detection at the project file stage is the earliest point in the chain.

The Stuxnet case

ATT&CK v20 records Stuxnet (S0603) copying itself into Step 7 projects so that it executes automatically when the project is loaded. Symantec's W32.Stuxnet Dossier (version 1.4, February 2011) gives the defensive detail:

• Step 7 projects: Stuxnet targeted project folders that looked recently used, skipped Siemens example projects, stored encrypted copies of itself in a project subfolder named "xutils", dropped a DLL under a "hOmSave7" subfolder, and changed a project data file so the engineering software loaded that DLL when the project opened.
• WinCC projects: projects with a "GracS" folder were candidates; Stuxnet stored its module there, and opening an infected project could spread infection to the connected WinCC database server.
• Hiding from the engineer: Stuxnet replaced the Step 7 communication library s7otbxdx.dll, renaming the original, and intercepted the functions that read, write and enumerate code blocks, so the engineer's own tools did not show the malicious blocks on the PLC.

Two lessons follow. Unexpected folders and files inside a project are an indicator, and inspecting the PLC through the same workstation that may be compromised is not proof of clean logic. Compare against an approved copy held elsewhere.

ATT&CK's Windows analytic also cites Havex, which reached engineering environments as trojanised vendor software and installers from compromised vendor websites, as a documented mechanism. That route is covered under the MITRE ATT&CK for ICS T0862 Supply Chain Compromise page.

Detection: ATT&CK v20 analytics

MITRE's detection strategy DET0766 has two analytics, both gated to alert only when activity breaks an approved signer, hash, path, parent, process or tool allowlist, or comes from an unauthorised user or tool, and suppressing vendor-signed software, approved engineering utilities and documented maintenance.

Add two checks the analytics do not cover. First, scheduled hash comparison of the project repository against the approved versions, which catches changes made while monitoring was down. Second, comparison of the program running in each controller with the approved project, using a workstation and tool you trust, after any unexplained change. See the File Integrity Monitoring Guide.

Prevention: the mitigations in practice

• Control where projects come from: open projects only from the approved repository, not from email, removable media or integrator laptops, unless they pass a review and hash check first. See the MITRE ATT&CK for ICS T0847 Replication Through Removable Media page.
• Treat integrator deliveries as untrusted: compare a delivered project with the previous approved version and review the differences before it is accepted.
• Limit download paths: allow program download to controllers only from named engineering workstations, so an infected project elsewhere cannot reach the PLC. CISA's AA22-103A advice likewise limits ICS connections to approved engineering workstations and keeps offline configuration backups verified by hashing. See the PLC Security Guide.

Where identity fits

M0922 only works if accounts are named. Shared engineering logons and integrator accounts left active make every write look authorised and every infected file untraceable. Give engineers and integrators individual accounts, grant write access per project, time-limit integrator access to the contract window, and keep signing keys under a separate identity that no engineering workstation account can use. See the OT and ICS Identity and Access Guide.

How to implement

1. Find every copy. Inventory where project files live: workstations, file shares, laptops, archives and integrator systems.
2. Create the approved baseline. With control engineers, confirm the current approved version of each project, ideally checked against the running controller, and record its hash in a repository.
3. Restrict permissions on the repository and project folders to named engineers, testing that the engineering software still works.
4. Turn on monitoring with object access auditing or auditd on project paths, and deploy DET0766-style alerts in alert-only mode through a maintenance cycle (our recommendation).
5. Add a pre-download check: verify the project hash or signature against the approved version before any download to a controller.
6. Keep a rollback: retain previous approved versions offline so a bad change, malicious or not, can be reverted under engineering supervision. See the OT Backup, Recovery and Golden Image Guide.

Decision guidance

• Hashing or signing: hashing against a protected repository is the minimum and works with any engineering software; signing adds tamper evidence that travels with the file but needs key management.
• Vendor project protection: use built-in password or encryption features where the software supports them, as an addition to repository controls, not a replacement.
• Small sites: one hardened engineering workstation, a read-only master copy on removable storage kept locked away and a hash list cover most of the risk.
• Large or multi-site estates: use a version-controlled project repository with change approval, automated hash comparison and monitoring on every engineering workstation.

Responding to a suspected infected project

Stop further downloads from the affected workstation and project before anything else, and tell operations which controllers may have received it. Preserve the suspect project, the workstation's disk and the engineering software's own files for analysis. Compare the suspect project with the approved version, and compare the running program in each affected controller with the approved version using a clean workstation, since the compromised one may hide changes. Restore approved programs under engineering supervision, then check every other copy of the project for the same infection. See the OT Incident Response Guide.

Detection and measurement

• Baseline coverage: percentage of controllers with an approved project version and recorded hash.
• Repository use: percentage of downloads made from the approved repository after a hash or signature check.
• Write access: number of accounts with write access to project files, tracked against named engineers.
• Monitoring coverage: percentage of engineering workstations with project path auditing forwarded centrally.
• Unexplained changes: count of project file changes without an approved change record, each investigated.

Framework mapping

Common failure patterns

• Many uncontrolled copies: projects on laptops, shares and email with no single approved version.
• Trusting the workstation's view: checking the PLC through the same tools Stuxnet showed can be subverted.
• Shared engineering accounts: nobody can say who changed a project file.
• Integrator projects accepted unreviewed: deliveries go straight to download without comparison.
• Signing keys on the workstation: an attacker on the host can sign their own changes.

Practitioner checklist

• Inventory every location that holds PLC and HMI project files.
• Keep approved versions in a protected repository with recorded hashes.
• Restrict write access to named engineers and technicians per project.
• Audit writes to project folders and alert on non-engineering processes.
• Verify hash or signature before every download to a controller.
• Keep signing keys off engineering workstations.
• Compare running programs with approved versions from a trusted workstation.
• Review and compare integrator deliveries before acceptance.

Standards and references

• MITRE ATT&CK for ICS: Project File Infection (T0873)
• MITRE ATT&CK: Detection of Project File Infection (DET0766)
• MITRE ATT&CK: Stuxnet (S0603)
• Symantec: W32.Stuxnet Dossier
• CISA and partners: AA22-103A, APT Cyber Tools Targeting ICS/SCADA Devices
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · Engineering Workstation Security Guide · PLC Security Guide · Code Signing Security Guide · ICS Malware History Guide