What should teams do first when malware is found on a control system?

Start by cutting the malware’s trust path, not by “cleaning” the box

The first move is to stop the malware from talking to anything it should not trust, while keeping the control process stable. On a control system, that usually means removing remote access routes, severing non-essential trust relationships, and coordinating the isolation with operations so you do not create a bigger process upset than the infection itself.

Isolation has to be deliberate in industrial environments because the infected host may still be part of a live control loop, historian path, engineering workflow, or remote support chain. If you disconnect the wrong component first, you can lose visibility or availability before you have contained the threat.

Preserve volatile evidence before you restart, reimage, or power down

Once the system is contained, collect the volatile evidence that will disappear first, such as running processes, network connections, logged-on sessions, and in-memory indicators. That evidence helps determine whether the malware is a loader, a dropper, a credential stealer, or a lateral movement foothold, which changes how far the incident may already have spread.

Do not trade evidence for speed unless the process risk is higher than the forensic value. In control environments, the right sequence is usually containment, volatile collection, then scope confirmation, because a premature reboot or cleanup can destroy the details you need to prove whether the malware reached engineering workstations, controllers, or remote support channels. See the Malware Guide for a deeper breakdown of common malware behaviours and the artefacts they leave behind.

Containment should be scoped to operations, not just the endpoint

The real question is not only whether the infected machine is compromised, but what it can still reach. If the system has access to remote administration, shared credentials, jump hosts, file shares, or vendor support paths, those paths should be treated as part of the incident scope and reviewed alongside the host itself.

That is why teams should coordinate with control-room staff, engineering, and OT operations before broad remediation begins. In practice, the containment decision has to balance process continuity against the possibility that the malware is already using trusted links to spread or harvest secrets. The Malware Loaders and Droppers Guide is useful when you need to judge whether the infection is likely to be a first-stage foothold rather than the full payload. For broader incident handling coordination, FIRST provides incident response coordination references that support disciplined handoff and communication.

Risk and Threat Considerations

Control-system malware is dangerous because the infected asset may sit inside both a cyber trust boundary and a physical process boundary. If responders move too slowly, the malware may retain access to operator credentials, engineering tools, or remote support channels; if they move too aggressively, they can interrupt control traffic or destabilise safety-relevant functions.

Failure mechanism: Malware uses existing trust relationships, remote access, or shared administration paths to persist, spread, or hide while defenders delay isolation to avoid process disruption.

Impact: The incident can expand from one host to engineering workstations, controllers, or adjacent environments, and cleanup can trigger availability loss, process instability, or missed evidence of lateral movement.

Practitioner Guidance

What to prioritise: Treat containment as an OT-safe isolation problem, not a desktop malware cleanup. Preserve the minimum process paths needed for safe operation, but remove any route that lets the malware communicate outward or reuse trust.

What to verify: Confirm whether the affected asset has remote support access, shared credentials, jump-box reach, or any pathway to engineering software before you decide how broad the containment needs to be. If those links exist, scope them as part of the incident, not as background infrastructure.

Decision rule: If the system can still authenticate to something outside its immediate control boundary, prioritise isolation and credential exposure review before attempting eradication. If the malware may have touched operator or service credentials, rotate them only after you understand which control functions depend on them.

Practitioner takeaway: The safest first action is usually to break the malware’s trusted reach, then gather the evidence needed to prove how far that trust was abused before you touch the process itself.

Related resources from NHI Mgmt Group

• What are the signs that a Linux system may be compromised by hidden remote-control malware?
• What should organisations do first when industrial control system devices cannot be quickly patched or replaced?
• What should security teams do first to prepare for destructive wiper malware that targets boot records and system files?
• What should security teams do first when a network access control system exposes an unauthenticated file upload endpoint?