A ransomware incident in an industrial environment does not need to begin with a compromised PLC. An attacker can instead target the infrastructure supporting operational systems, encrypting virtual machines, disrupting storage, or disabling recovery services while the controllers themselves remain untouched.

This is why OT ransomware protection must extend beyond PLCs and industrial protocols. Modern industrial environments increasingly depend on virtual machines, hypervisors, shared storage, backup platforms, databases, identity services, and management servers. Although these technologies may resemble conventional IT infrastructure, their failure can have direct operational consequences.

The challenge is therefore not only protecting industrial devices, but understanding which digital dependencies keep the environment observable, manageable, and recoverable. Effective OT resilience must consider whether operators can still see the process, whether recovery copies remain available, and whether compromising one shared system could affect several operational workloads at once.

Virtualisation Is Becoming Part of the OT Attack Surface

Ransomware operators increasingly target the infrastructure that organisations depend on rather than attacking every workload individually. CISA warns that modern ransomware strategies can target hypervisors and other centralised systems because compromising this layer can allow attackers to disrupt or encrypt multiple workloads at scale.

This is especially relevant to industrial environments, where a single virtualisation cluster may host SCADA applications, historians, alarm-management services, operational databases, and OT monitoring systems. Ransomware therefore creates a particular challenge because attackers do not necessarily need specialist knowledge of the physical process itself.

Once privileged infrastructure access is obtained, an attacker may be able to shut down virtual machines, remove recovery points, interfere with storage, or encrypt the files supporting several operational applications at once. CISA has also documented ransomware capable of targeting hypervisor environments, shutting down running virtual machines before encrypting associated files.

As a result, attackers may create significant operational disruption without directly manipulating a PLC or industrial protocol. Controllers might continue operating while monitoring, supervisory, and recovery systems become unavailable. What begins as a conventional ransomware intrusion can therefore become an OT availability and resilience problem.

Why Virtual Infrastructure Changes OT Risk

Virtualisation can simplify deployment, management, recovery, and redundancy; however, it can also concentrate risk because several applications that appear independent may rely on the same underlying infrastructure.

For example:

VM-SCADA-01 — Supervisory application
VM-HIST-02 — Industrial historian
VM-ALARM-01 — Alarm-management platform
VM-MON-03 — OT monitoring

All four may depend on the same Hypervisor OT-HV-01 and Datastore OT-SAN-01. Therefore, while a problem affecting one VM may disrupt only one workload, ransomware affecting the shared host or datastore could affect all four simultaneously.

Traditional asset monitoring tends to ask, “What system generated the alert?” OT resilience must go further and ask, “What else stops working if this system fails?”

From Virtual Infrastructure to Operational Risk

1. Map the Digital Dependencies Behind OT

The first step is understanding which infrastructure supports operational workloads.

Relevant systems can include:

• Hypervisor hosts
• Virtualisation management systems
• Shared storage
• Backup servers and repositories
• Virtual machines
• Database servers
• Authentication services
• Disaster-recovery infrastructure
• Operational application servers

The inventory should document more than the hostname and operating system.

Context	Example
Asset	OT-HV-01
Function	OT virtualisation host
Hosted workloads	SCADA, historian, alarm server
Storage dependency	OT-SAN-01
Backup dependency	OT-BACKUP-02
Criticality	Critical
Vulnerabilities	3 open findings
Recovery priority	Tier 1

This context changes prioritisation because a vulnerability affecting a standard application server is one problem, while the same vulnerability affecting a hypervisor that hosts several operational services may represent a significantly larger operational risk.

The Logstail Security Suite combines SIEM monitoring with asset inventory, vulnerability scanning, patch management, cases, and response workflows, allowing security teams to connect infrastructure activity with the assets affected by it.

2. Monitor the Virtualisation Management Plane

The hypervisor itself is only part of the attack surface.

The management plane controlling the environment may provide access to many operational workloads simultaneously.

A virtualisation administrator can legitimately:

• Power off virtual machines
• Create or delete snapshots
• Modify storage
• Change virtual networking
• Access virtual consoles
• Move workloads between hosts
• Modify administrative permissions

The same functionality becomes dangerous when used by an unexpected identity or outside approved infrastructure activity.

High-value telemetry can include:

• New virtualisation administrators
• Privilege changes
• Unusual management-console authentication
• Mass VM enumeration
• Unexpected VM shutdowns
• Snapshot deletion
• Datastore changes
• Virtual-network modifications
• Management API activity
• Security logging being disabled

Logstail SIEM can centralise these events and correlate them with identity, asset, vulnerability, and infrastructure information.

The useful detection is not simply:

Someone authenticated to the hypervisor.

It is:

An unusual privileged identity accessed an OT virtualisation environment and performed high-impact actions against operational workloads.

What Could This Look Like in Practice?

A single administrative session can progress from legitimate-looking access to operational disruption within only a few actions. The sequence below illustrates how activity against the virtualisation management plane can move from authentication and privilege modification to destructive changes and eventual service loss.

 

3. Detect Recovery Destruction Before Encryption

Ransomware is not only about encryption. Attackers may first weaken the organisation’s ability to recover, making backup and snapshot activity an important early-warning opportunity.

In practice, a privileged account might access backup management, disable recovery jobs, delete VM snapshots, modify retention policies, and make repositories unavailable before operational virtual machines are finally shut down or encrypted.

Therefore, the encryption event may not be the earliest or most useful detection point. Mass snapshot deletion, backup-job cancellation, repository removal, retention-policy changes, backup-service shutdown, and unexpected recovery-point deletion can indicate that an attacker is preparing the environment for maximum impact.

The critical question becomes: if these operational applications disappear, can we still recover them?

4. Correlate Failures Across Shared Infrastructure

An infrastructure-level incident may initially appear as several unrelated failures.

For example:

10:03 — Historian unavailable

10:04 — Alarm-management service unavailable

10:04 — OT monitoring VM unreachable

10:05 — SCADA database unavailable

These could generate four separate alerts. However, if all four workloads depend on OT-HV-02 and OT-SAN-01, the investigation changes completely.

Instead of asking why four applications failed independently, the SOC can investigate what happened to their shared infrastructure. Several unavailable VMs, common host and storage dependencies, recent administrative activity, cluster or datastore events, and privileged identity activity can then be correlated into a stronger incident:

Multiple operational workloads became unavailable following suspicious activity against shared virtualisation infrastructure.

This is the value of connecting security events with asset dependencies.

5. Prioritise According to Operational Blast Radius

Technical severity alone does not always represent operational risk. Consider two vulnerable hypervisors: Host A supports internal reporting, development, and testing, whereas Host B supports the historian, alarm management, OT monitoring, and a production database.

The vulnerability severity may be identical, even though the operational consequence is not. Thus, prioritisation should also consider asset criticality, the number of dependent workloads, operational function, recovery capability, redundancy, backup status, and potential availability impact.

A simple model could be:

Infrastructure Risk = Technical Severity × Asset Criticality × Dependency Blast Radius × Recovery Impact

The purpose is not to introduce another complicated scoring model, but to ensure that infrastructure whose failure could have the greatest operational consequence is prioritised accordingly.

High-Value Detection Scenarios

Mass Snapshot Deletion

One deleted snapshot may represent legitimate maintenance; several snapshots disappearing across production-supporting VMs within minutes is different. If the activity occurs outside an approved maintenance period, or is performed by an identity that does not normally manage recovery infrastructure, the SOC should correlate it with recent privileged access, backup configuration changes, and activity on the affected hypervisor.

This matters because snapshot deletion may occur before encryption, giving defenders an opportunity to investigate while recovery options still exist.

Multiple Operational VMs Powered Off

A single VM shutdown may indicate an ordinary application or infrastructure issue. However, several SCADA, historian, monitoring, or database workloads shutting down within the same period can point to a shared infrastructure problem.

If those systems share the same host, datastore, or administrative identity, the investigation should move away from individual service availability and toward the virtualisation layer beneath them.

Unexpected Virtualisation Administrator Creation

Increase severity when a newly privileged account immediately enumerates or modifies production-supporting infrastructure.

Datastore Disruption

Correlate storage changes with several operational workloads becoming unavailable simultaneously.

Backup Infrastructure Manipulation

Treat backup-job cancellation, repository removal, or mass recovery-point deletion as potential early ransomware behaviour.

Loss of Visibility While Controllers Continue Operating

If historians, monitoring systems, or supervisory applications stop reporting while independent OT telemetry indicates that controllers remain active, the SOC must determine:

Did the process stop, or did we lose our ability to see it?

Logstail Security Suite: Connecting the Incident

Virtualised OT infrastructure can generate evidence across hypervisors, virtual machines, storage, backups, identities, vulnerabilities, applications, and network infrastructure; however, investigating those systems independently can hide the common cause.

The Logstail Security Suite provides a shared security-operations layer for monitoring, asset visibility, vulnerability information, alerts, investigations, cases, and response workflows.

A ransomware investigation can therefore connect the infrastructure event with the affected asset, dependent operational workloads, related alerts, incident context, and the eventual response. The objective is not only to identify that something happened, but to understand why the affected infrastructure matters to the operation.

Response workflows can then enrich the incident, identify dependent workloads, validate recovery state, notify the responsible teams, and preserve human approval for actions that could affect production.

Example Response Flow

Here is an example of how that response flow could look in practice: related infrastructure alerts are brought into one investigation, affected workloads are identified, recovery state is checked, and high-impact actions remain controlled.

 

AICOT: Extending Visibility Deeper into OT

Supporting infrastructure is only one layer of the industrial security problem; the next layer exists closer to the industrial process itself.

Logstail is leading AICOT — AI-Driven Cyber Defense Platform for Operational Technology Environments in Critical Infrastructure. AICOT builds on Logstail’s existing SIEM and data-analytics capabilities and is intended to extend them with machine learning, anomaly detection, OT protocol analysis, behavioural monitoring, and AI-assisted threat detection.

In this model, Logstail provides visibility around the infrastructure that industrial operations depend on, while AICOT extends that direction deeper into OT-specific communication and behaviour.

Conclusion

Ransomware does not need to compromise a PLC to create an OT incident; a compromised hypervisor, datastore, backup platform, or virtual server can affect the applications that keep an industrial environment visible, manageable, and recoverable.

This is why OT ransomware protection needs to account for the infrastructure behind the physical process, not only the controllers within it. The Logstail Security Suite helps connect infrastructure activity with asset and operational context, while AICOT extends that visibility toward OT-native monitoring and AI-assisted detection.

Understanding these dependencies gives defenders a better chance to detect destructive behaviour earlier, preserve recovery options, and prevent a conventional ransomware intrusion from becoming an operational disruption.

The AICOT project has received funding from the European Union’s Digital Europe Programme under Grant Agreement No. 101249826. Views and opinions expressed are those of the authors only and do not necessarily reflect those of the European Union or the European Cybersecurity Competence Centre.

Contact Our Experts or Sign Up for Free