Introduction

Critical infrastructure environments present a unique challenge for both attackers and defenders. Unlike standard enterprise networks where the objective is data, critical infrastructure targets carry operational consequences: power grids lose load, water treatment plants alter chemical dosing, manufacturing lines halt, and transportation systems fail. The adversary's objective in these environments is not always exfiltration. It is often pre-positioning for disruption at a time of their choosing.

This report draws on observations from red team engagements conducted against organizations operating in the energy, water, transportation, and manufacturing sectors. It examines the techniques that consistently succeed against environments that consider themselves hardened, the assumptions defenders make that create persistent blind spots, and the lateral movement patterns that allow an attacker to traverse from an IT network foothold into operational technology (OT) environments where the real damage occurs.

The perspective throughout is adversarial. We are not cataloging theoretical attack paths. We are documenting what works in practice against organizations that have invested in security, employ security teams, run detection platforms, and still get compromised during controlled engagements.

The Initial Access Problem

Critical infrastructure organizations often invest heavily in perimeter security. Firewalls are layered. VPN access requires MFA. Email gateways filter malicious attachments. Network segmentation separates IT from OT. On paper, the perimeter is strong.

In practice, initial access consistently comes through three vectors that perimeter defenses do not adequately address.

1. Vendor and Contractor Access

Every critical infrastructure organization depends on third-party vendors for maintenance, monitoring, and support. These vendors have remote access to systems that sit at or near the IT/OT boundary. The vendor's VPN credentials, their jump host, their service account in Active Directory, and their remote desktop session into a SCADA workstation represent a trust relationship that bypasses the organization's perimeter entirely.

During engagements, we consistently find that vendor accounts have excessive permissions, static credentials that have not been rotated in years, and access that persists long after the maintenance window closes. In one engagement against a water utility, a single vendor account had RDP access to three SCADA workstations, domain admin equivalent privileges in the OT domain, and a password that had not changed in 14 months. The vendor's own security posture was not assessed by the utility at any point during the contract.

The attacker model here is straightforward: compromise the vendor (who typically has weaker security than the infrastructure operator), inherit their access, and walk into the target environment through a trusted channel that generates no alerts because it looks exactly like legitimate vendor activity.

2. Exposed Engineering Interfaces

Industrial control systems were not designed for networked environments. Many were built decades before cybersecurity was a design consideration. When these systems are connected to IP networks for remote monitoring, management convenience, or integration with enterprise systems, the engineering interfaces (web consoles, Telnet/SSH, proprietary protocols) are often exposed to segments that are reachable from the IT network or, in worst cases, directly from the internet.

Shodan and Censys scans consistently reveal PLCs, RTUs, HMIs, and engineering workstations that are directly internet-accessible at critical infrastructure operators. During one engagement against a regional power utility, we identified 14 Modbus-accessible devices on the public internet with no authentication. These were not honeypots. They were production RTUs controlling substation equipment. The utility's IT team was unaware they were exposed.

The gap exists because the people who configure these devices (control engineers) are not security practitioners, and the people who manage security (IT security teams) often lack visibility into OT network architecture. Neither team owns the problem fully, which means it persists.

3. Social Engineering Against Operations Personnel

Control room operators, field technicians, and maintenance engineers are trained to keep systems running. They are not trained to identify phishing campaigns. In critical infrastructure environments, we observe a cultural emphasis on availability over security that manifests in predictable ways: shared credentials for HMI workstations, passwords taped to monitors in control rooms, USB drives used to transfer files between air-gapped and connected networks, and a general resistance to security controls that introduce friction into operational workflows.

Phishing campaigns targeting operations personnel consistently achieve higher success rates than campaigns targeting IT staff in the same organization. The content that works is not generic. It is operationally relevant: fake vendor maintenance notifications, simulated regulatory compliance requests, and spoofed SCADA alarm emails. When the phishing payload matches the target's daily work context, click rates exceed 30% in nearly every engagement.

Lateral Movement in Segmented Environments

The core defensive assumption in critical infrastructure is that network segmentation prevents an IT compromise from reaching OT systems. In theory, the IT and OT networks are separated by firewalls, data diodes, or DMZs. In practice, the segmentation is almost always imperfect, and the imperfections are where lateral movement succeeds.

The Historian as a Pivot Point

The data historian is the single most consistent pivot point from IT to OT networks in critical infrastructure environments. Historians collect process data from OT systems and make it available to business applications on the IT network. By design, they have network connectivity to both zones. They run on Windows. They are domain-joined. They store data that operations, engineering, and business intelligence teams all need access to.

From an attacker's perspective, the historian is the bridge. Compromise a historian server, and you have a machine that can talk to both the IT domain (where you already have credentials) and the OT network (where the targets are). In multiple engagements, we have used compromised historian servers to enumerate OT network assets, identify PLCs and HMIs, and establish command-and-control channels that cross the segmentation boundary without triggering any alerts, because the historian's network traffic to OT devices is expected and baseline-normal.

Dual-Homed Engineering Workstations

Engineering workstations that are connected to both the IT and OT networks are another reliable pivot. These machines are used by control engineers to program PLCs, configure HMIs, and troubleshoot control system issues. They often have two network interfaces: one on the corporate LAN and one on the OT network or a dedicated engineering VLAN that has direct access to control system components.

These workstations are frequently running outdated operating systems (Windows 7 and Windows 10 are still common in OT engineering environments in 2026) because the control system vendor has not certified their software for newer OS versions. They often have antivirus disabled or excluded from coverage because the vendor's installation guide said to, and no one revisited that decision. They are high-value targets that combine privileged OT access with IT-network reachability and weak local security controls.

Shared Credentials Across Zones

In environments where IT and OT Active Directory domains are separate (which is the recommended architecture), we consistently find that administrators use the same passwords across both domains. The IT domain admin password and the OT domain admin password are identical because the same person manages both, and they reuse credentials out of convenience.

In environments where a single Active Directory domain spans both IT and OT (which is more common than it should be), the problem is worse. A credential harvested from an IT-side workstation via Mimikatz or similar tools often works directly on OT-side systems because they share the same domain. Kerberos tickets obtained from IT-side domain controllers are valid for OT-side services. The segmentation at the network layer is undermined by identity convergence at the authentication layer.

Persistence in OT Environments

Once an attacker reaches the OT network, the persistence model changes. IT-style persistence (scheduled tasks, registry run keys, WMI subscriptions) works on Windows-based HMIs and engineering workstations. But the more concerning persistence mechanisms are the ones that live on the control system components themselves.

PLC Logic Modification

PLCs execute ladder logic, function blocks, or structured text that defines how a physical process operates. An attacker with access to the engineering workstation and the PLC programming software can modify the logic running on the PLC itself. This modification persists across reboots, survives network disconnections, and is invisible to anyone who does not compare the running logic against a known-good baseline.

The defensive challenge is that most organizations do not maintain verified baselines of PLC logic. When they do, the comparison process is manual, infrequent, and performed by the same engineers who programmed the PLC in the first place. Automated PLC logic integrity monitoring is still rare outside the most mature critical infrastructure operators.

From a red team perspective, PLC logic modification is the most durable form of persistence in an OT environment. It survives incident response activities that focus on IT systems (reimaging workstations, resetting passwords, rebuilding servers). Unless the response team specifically inspects and validates PLC logic, the attacker's modifications remain in place after the "remediation" is complete.

Firmware Implants on Network Equipment

Managed switches, routers, and firewalls that sit between IT and OT zones are targets for firmware-level persistence. An attacker who compromises one of these devices and modifies its firmware can maintain access to both network zones, intercept and modify traffic, and survive factory resets that do not include firmware reflashing.

The Volt Typhoon campaign documented by CISA and FBI demonstrated this technique at scale against U.S. critical infrastructure, using compromised SOHO routers as operational relay boxes. At the enterprise level, the same principle applies to managed network infrastructure within the OT DMZ. These devices are rarely included in vulnerability scanning, patch management, or integrity monitoring programs because they are "infrastructure" rather than "endpoints."

Detection Gaps That Persist

Critical infrastructure organizations have invested significantly in detection capabilities over the past five years, driven by regulatory requirements (NERC CIP, TSA Security Directives, EPA cybersecurity mandates) and high-profile incidents (Colonial Pipeline, Oldsmar water treatment, Volt Typhoon). Despite this investment, consistent detection gaps remain.

Lack of East-West Visibility in OT Networks

Most OT network monitoring is deployed at the IT/OT boundary. Traffic between IT and OT is inspected. But traffic within the OT network, between PLCs and HMIs, between engineering workstations and controllers, between historians and RTUs, is often not monitored at all. Once an attacker crosses the boundary, they operate in a zone with minimal detection coverage.

This gap exists because deploying monitoring within OT networks is operationally complex. OT networks use proprietary protocols, operate at tight timing tolerances, and cannot tolerate the latency or disruption that misconfigured monitoring can introduce. Network taps and passive monitoring solutions exist, but deployment requires coordination between security teams and control engineers, which is often difficult to achieve organizationally.

Alert Fatigue from IT-Centric Tools

When organizations do deploy security monitoring in OT environments, they often use IT-centric SIEM platforms that are not tuned for OT traffic patterns. The result is a flood of false positives from legitimate OT protocols and communications that the SIEM does not understand. Analysts learn to ignore alerts from OT sources because they are almost always noise. This creates a detection blind spot that persists even when monitoring is technically deployed.

No Behavioral Baseline for Control System Communications

OT networks are paradoxically ideal for behavioral detection because they are highly predictable. A PLC talks to the same HMI, at the same interval, using the same protocol, with the same payload size, every cycle. Any deviation from that pattern is anomalous by definition. But most organizations have not established these baselines. Without a baseline, any traffic pattern looks normal, including attacker traffic that mimics legitimate communications.

Recommendations for Defenders

Map every trust relationship that crosses the IT/OT boundary. Every vendor connection, every historian, every dual-homed workstation, every shared credential, every firewall rule that allows traffic from IT to OT. You cannot defend a boundary you have not fully mapped. This mapping exercise is the single highest-value activity a critical infrastructure security team can undertake.

Treat vendor access as a persistent threat vector. Require MFA for all vendor remote access. Implement just-in-time access that activates only during approved maintenance windows and deactivates automatically. Monitor vendor sessions with the same rigor you apply to privileged internal access. Assess vendor security posture as a contractual requirement, not a courtesy.

Establish and maintain PLC logic baselines. Download, hash, and store the logic from every PLC in your environment. Compare running logic against baselines on a regular schedule. Automate this process where your control system vendor supports it. This is the only reliable defense against the most durable form of OT persistence.

Deploy passive monitoring inside the OT network, not just at the boundary. Use OT-native network detection tools (Claroty, Dragos, Nozomi Networks, or similar) that understand industrial protocols and can establish behavioral baselines for control system communications. Position monitoring at the switch level within OT VLANs, not just at the firewall between IT and OT.

Separate identity across zones completely. IT and OT should not share an Active Directory domain. If they must share a forest, enforce administrative tiering that prevents IT-side credentials from authenticating to OT-side systems. At minimum, ensure that no administrator reuses passwords across domains. Credential reuse is the single most common way that network segmentation is bypassed in practice.

Conduct red team engagements that include OT scope. Penetration tests that stop at the IT/OT boundary do not test the defenses that matter most. Red team engagements against critical infrastructure should explicitly include OT networks, control system components, and physical access vectors. The objective should be to demonstrate (safely) whether an attacker can reach the systems that control physical processes, not just the systems that store data.

Key Takeaway

  • The organizations that operate critical infrastructure are not failing because they lack security tools or budgets. They are failing because the assumptions embedded in their defensive architecture do not match the adversary's actual attack path. Segmentation is undermined by trust relationships. Detection is deployed at boundaries but not within zones. Persistence mechanisms target control system components that incident response teams do not inspect. The adversary perspective is not a theoretical exercise. It is the lens through which every defensive investment should be validated.