MITRE ATT&CK for ICS T0862 Supply Chain Compromise: Detection and Response in OT

Supply Chain Compromise (T0862) is how an adversary reaches a control system without attacking it directly: the asset owner installs the compromised product themselves. In OT that product might be a trojanised engineering software installer from a vendor website, a tampered firmware image, a patch delivered by an integrator, or a counterfeit field device that looks genuine. MITRE ATT&CK for ICS lists T0862 under Initial Access for Embedded, Windows, Linux and Network Devices platforms. This guide is for OT security engineers, control system engineers and the people who accept vendor deliveries: how the technique works in industrial settings, what ATT&CK's v20 analytics look for, which acceptance and integrity controls stop it, and how to respond without causing a plant upset. For the enterprise software supply chain, including package registries and CI/CD, see the MITRE ATT&CK T1195 Supply Chain Compromise guide; this page covers what is different in OT.

Key takeaways

• The delivery path is the attack surface. Vendor download portals, update servers, integrator laptops, spare parts and replacement hardware all carry software and firmware into OT, and each needs a verification step.
• Havex set the pattern. ATT&CK records Dragonfly planting trojanised installers on legitimate ICS vendor websites, so the "official" download was the infection.
• Counterfeit hardware is part of the technique. ATT&CK includes counterfeit field devices carrying a real manufacturer's logo, which bring safety risk as well as cyber risk.
• Detection compares against the vendor's own baseline. ATT&CK's v20 analytics check installed hashes against vendor-published checksums and installer behaviour against a documented install profile.
• Acceptance testing is the cheapest control. Hash checks, signature checks and a staging test before anything reaches production catch most tampering before it can act.

What T0862 covers and how it differs from T1195

ATT&CK for ICS defines T0862 as manipulating products, such as devices or software, or their delivery mechanisms before receipt by the end consumer, with the goal of compromising data or systems once the infected product is introduced into the target environment. It can happen at any stage, from development tools and environments to distribution, and it explicitly includes replacing legitimate software and patches on third-party or vendor websites. The description also notes that in environments with assets in both IT and OT domains, a compromise aimed at IT can still reach control systems.

T0862 often works together with other ICS techniques. The trojanised software reaches an engineering workstation, which then enables Program Download (T0843) or Project File Infection (T0873), and integrator laptops overlap with Transient Cyber Asset (T0864). See the MITRE ATT&CK for ICS Guide for the matrix.

The procedure examples and what they teach

• Havex and Dragonfly (G0035): ATT&CK records Dragonfly trojanising legitimate ICS equipment providers' software packages on their websites, and Backdoor.Oldrea (S0093), the Havex remote access trojan, being distributed through trojanised installers on compromised vendor sites. The lesson is that a download from the right vendor domain is not proof of integrity. See the Berserk Bear Threat Actor Profile Guide and the ICS Malware History Guide.
• TEMP.Veles (G0088): ATT&CK records the group targeting several ICS vendors and manufacturers. Vendors are targets in their own right because one compromise reaches many asset owners.
• Counterfeit transmitters: ATT&CK cites an automation manufacturer identifying customers who had received counterfeit differential pressure transmitters bearing its logo, nearly indistinguishable from the genuine product. Counterfeit devices may not meet safety, engineering and manufacturing requirements even when tagged as conforming.

Where tampering enters an OT environment

Third parties are part of this picture: integrators often hold the media, credentials and project files that move into the plant. See the OT Third-Party and Integrator Access Guide.

Detection: ATT&CK v20 analytics

MITRE's v20 detection strategy for T0862 (DET0730) has four platform analytics. All of them share what ATT&CK calls an OT operational fidelity gate: alert only when execution breaks an approved signer, hash, path, parent process or tool allowlist, or comes from an unauthorised user or tool, and ties to an OT asset or follow-on OT-relevant action, while suppressing vendor-signed software, approved engineering utilities and documented maintenance.

The two tunable inputs ATT&CK names are the vendor install manifest (the files and registry keys a genuine installer creates) and the vendor install profile (expected process behaviour, established through lab testing). Building them is the real work: install each vendor package in a staging environment, record what it does and keep that record with the asset register. Continuous monitoring from an OT network sensor adds a second view, flagging new protocols or destinations after an update. See the OT Network Security Monitoring Guide.

Prevention: ATT&CK mitigations in practice

• M0817 Supply Chain Management: assess supplier trustworthiness and technical maturity, and require technical means such as code signing and bills of materials to validate integrity. IEC 62443-4-1 gives the secure development lifecycle requirements to ask suppliers for; see the IEC 62443-4-1 and 4-2 Secure Product Development Guide and the OT Product Procurement Guide.
• M0945 Code Signing: where available, use hardware and software roots of trust to verify critical software and firmware through signatures or hashes. Turn on signed firmware enforcement on devices that support it, after confirming rollback procedures with the vendor.
• M0947 Audit: run periodic integrity checks of devices to validate firmware, software, programs and configuration against known-good baselines.
• M0951 Update Software: run a patch process that also checks for unused, unmaintained or previously vulnerable dependencies and unnecessary components.
• M0916 Vulnerability Scanning: monitor vulnerability sources continuously for the products you run, so a compromised or recalled version is noticed. See the ICS Advisory Triage and OT Vulnerability Management Guide.

For hardware, add authorised channel purchasing, receipt inspection and firmware verification before commissioning. The Hardware and Firmware SBOM Guide covers component records.

Where identity fits

The delivery mechanisms in T0862 run on accounts and keys: the vendor's code signing key, the integrator's portal and remote access accounts, the service account that pulls updates into a DMZ repository. A signature only proves that someone holding the signing key published the file, so ask suppliers how they protect signing keys and how they would revoke one. Inside the plant, restrict who can install software on engineering workstations and HMIs to named engineering accounts, and remove standing administrator rights from integrator accounts outside agreed work windows. See the OT and ICS Identity and Access Guide.

How to implement

1. Inventory what enters OT. List every software product, firmware family and hardware type in use, with its supplier, delivery route and who brings it in.
2. Set up a staging and acceptance step. A DMZ repository or media kiosk where every installer, patch and firmware image is checked for signature and published hash, scanned and recorded before transfer.
3. Build install manifests and profiles for the top vendor packages by installing them in a test environment and recording files, services and process behaviour.
4. Baseline firmware hashes for controllers, modules and network devices, using vendor tools or the asset inventory platform, and schedule re-checks after every update or replacement.
5. Deploy DET0730-style alerts in alert-only mode during the next maintenance outage cycle (our recommendation), suppressing approved installs logged against change tickets.
6. Write supplier requirements into contracts: signed deliveries, published hashes, bills of materials, notification of supplier compromise and key revocation procedures.
7. Keep a rollback for every update: the previous approved installer, firmware image and controller program, stored offline. See the OT Backup, Recovery and Golden Image Guide.

Decision guidance

• Small sites with few vendors: a documented manual check (signature, hash, scan, record) on a dedicated transfer machine covers most of the risk without new tools.
• Larger estates: an OT asset inventory platform with firmware hash tracking and a managed DMZ repository makes the checks repeatable and auditable.
• Devices without signature support: rely on published hashes, receipt inspection and post-install integrity checks, and plan replacement with products that support signed firmware.
• Vendor remote update services: prefer staging through an asset owner controlled repository over direct vendor push into OT, accepting slower delivery in exchange for a verification point.

Responding to a suspected supply chain compromise

Start with impact analysis together with operations: which assets run the suspect product or version, what they control and whether the process can run safely without them. Preserve evidence before changing anything: the installer or firmware image, hashes, install logs, device configuration and controller program. Contain at the conduit first, by blocking the suspect product's outbound communication and vendor connectivity, rather than pulling supervisory hosts off the network mid-process. Contact the vendor through a known channel, not one listed in the suspect package, and report to your national authority. Recover by reinstalling from a verified source or the last approved offline copy, re-verify firmware hashes on every affected device, and replace any hardware that cannot be verified. For counterfeit devices, treat safety first: confirm with process safety engineers whether the device can stay in service until replaced. See the OT Incident Response Guide.

Detection and measurement

• Verification coverage: percentage of software and firmware transfers into OT in the last quarter with a recorded signature or hash check.
• Firmware baseline coverage: percentage of controllers, modules and network devices with a recorded authorised firmware hash.
• Install profile coverage: percentage of top vendor packages with a lab-built install manifest and profile.
• Supplier requirement coverage: percentage of active OT suppliers with signed delivery and compromise notification clauses in contract.
• Post-update integrity checks: percentage of updates followed by a firmware or file integrity re-check within one week.

Framework mapping

Common failure patterns

• Trusting the vendor domain: downloading from the right website and skipping hash and signature checks, the exact gap Havex used.
• Hashes checked against the same page as the download: if the site is compromised, both can be replaced; use a separate channel or the signature.
• Integrator media accepted without a kiosk: project files and tools on contractor laptops reach engineering workstations unchecked.
• Grey market spares in an emergency: a fast replacement from an unverified source can bring counterfeit hardware into a safety-relevant loop.
• No firmware baseline: without recorded authorised hashes there is nothing to compare against after an update.

Practitioner checklist

• List every product, firmware family and hardware type in OT with its supplier and delivery route.
• Route all software and firmware through a staging point that checks signatures and published hashes from a separate channel.
• Build install manifests and profiles for key vendor packages in a test environment.
• Record authorised firmware hashes for controllers, modules and network devices and re-check after each change.
• Buy hardware through authorised channels and verify firmware before commissioning.
• Put signed delivery, bill of materials and compromise notification requirements into supplier contracts.
• Keep offline copies of the last approved installers, firmware and controller programs.
• Write a response runbook that starts with impact analysis and contains at the conduit.

Standards and references

• MITRE ATT&CK for ICS: Supply Chain Compromise (T0862)
• MITRE ATT&CK: Detection of Supply Chain Compromise (DET0730)
• NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• CISA and partners: Secure by Demand, Priority Considerations for OT Owners and Operators when Selecting Digital Products
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · MITRE ATT&CK T1195 Supply Chain Compromise · OT Product Procurement Guide · OT Third-Party and Integrator Access Guide · Engineering Workstation Security Guide