Living Off the Land Attacks in OT: The Microsegmentation Fix

The Dragos 2026 OT Cybersecurity Year in Review confirmed something I've been hearing in every OT security conversation for the past six months: adversaries are not bringing their own malware to operational technology networks. They're living off the land, using what's already there.

Dragos now tracks 26 threat groups targeting industrial control systems, including three new groups identified in 2025: AZURITE, PYROXENE, and SYLVANITE. Each one demonstrates a level of OT protocol fluency that makes traditional detection methods nearly useless. AZURITE targets engineering workstations to exfiltrate network diagrams and alarm data. PYROXENE conducts multi-year supply chain campaigns, including social engineering via fake LinkedIn recruiter profiles, and deployed custom wiper malware in June 2025. SYLVANITE operates as an initial access broker, rapidly weaponizing edge device vulnerabilities and handing off footholds to groups like VOLTZITE for deeper OT intrusion. And KAMACITE, an established group, expanded from Ukraine-focused operations to systematically scanning U.S. industrial control loops, including HMIs, variable frequency drives, and metering modules.

Here's the thing: 56% of Dragos penetration tests in 2025 successfully abused living off the land tools without triggering a single alert. Meanwhile, 81% of architecture assessments identified poor IT/OT segmentation. These two numbers are not a coincidence. They are the same problem.

Living off the land attacks in OT environments are fundamentally a segmentation problem, not a detection problem. And the sooner OT security leaders internalize that distinction, the faster they can build architectures that actually constrain these threats.

Living Off the Land in OT Is Not the Same as in IT

In IT environments, living off the land (LOTL) typically means abusing PowerShell, WMI, PsExec, or other built-in Windows administration tools to move laterally and execute payloads without dropping custom malware. It's a well-understood problem with a growing ecosystem of detection tools. EDR platforms, SIEM correlation rules, and behavioral analytics have all gotten better at flagging suspicious use of these legitimate binaries.

OT living off the land is a different animal entirely.

When adversaries reach the control network, they don't need PowerShell. They have native industrial protocols: Modbus/TCP, EtherNet/IP, OPC-UA, DNP3, IEC 104. These protocols were designed decades ago for reliability and real-time performance, not security. Most carry no authentication. Many lack encryption. A legitimate read command from an engineering workstation looks identical to a malicious reconnaissance query from a compromised one.

The MITRE ATT&CK for ICS framework captures this under T0869 (Standard Application Layer Protocol) and T0855 (Unauthorized Command Message). An attacker who understands EtherNet/IP can issue a valid CIP (Common Industrial Protocol) command to an Allen-Bradley ControlLogix PLC, and the PLC will execute it. No exploit needed. No vulnerability required. The protocol does exactly what it was designed to do.

This is what made PIPEDREAM (also known as INCONTROLLER), the malware toolkit attributed to the CHERNOVITE threat group, so significant when it was discovered in 2022. PIPEDREAM didn't rely on software vulnerabilities. Its MOUSEHOLE module used legitimate OPC-UA protocol interactions to enumerate and manipulate Schneider Electric and Omron PLCs. Its capabilities demonstrated that an adversary fluent in OT protocols could achieve process disruption using nothing but native protocol commands. CISA, NSA, and the FBI issued a joint advisory specifically because PIPEDREAM's LOTL approach represented a new category of OT threat.

Why Your Endpoint Detection Tools Are Blind in OT

I talk with OT security managers who have invested heavily in endpoint detection and response (EDR) tools, extended their IT security stack into the plant floor, and still feel exposed. In practice, they are right to feel that way.

The core problem is coverage. EDR requires an agent running on the endpoint. That works for Windows engineering workstations and historian servers. It doesn't work for the Siemens S7-300 PLCs controlling a batch process, the Schweitzer Engineering relay protecting a substation feeder, or the legacy HMI running Windows XP Embedded with 512MB of RAM. These devices can't run agents. Many can't be patched. Some can't even be rebooted without a scheduled maintenance window.

Dragos reported that 88% of tabletop exercises in 2025 revealed degraded detection capabilities across OT environments. The SANS analysis of the Dragos 2026 report put it directly: "visibility gaps, not zero-days, drive most failures."

Even where agents are deployed, they create a false positive problem specific to OT. Engineering workstations routinely use the same tools that attackers abuse: remote desktop connections to HMIs, firmware upload utilities, protocol analyzers, configuration management software. A security analyst looking at EDR telemetry from an engineering workstation sees a stream of activity that is indistinguishable from normal operations unless they deeply understand the plant's operational context.

The TRITON attack on a Saudi petrochemical facility in 2017 (attributed to the XENOTIME threat group) illustrates this perfectly. The attackers moved from the corporate network to the OT environment using captured credentials and standard remote access tools, including PSExec and RDP. They were present on the corporate network for over a year before pivoting to the safety instrumented system (SIS). No endpoint tool flagged the lateral movement because every individual step used legitimate administrative capabilities.

To be clear: I'm not arguing that OT visibility tools like Dragos, Claroty, or Nozomi Networks are unnecessary. They provide critical protocol-level monitoring. But monitoring alone tells you what happened. It doesn't prevent the movement from happening in the first place.

The Lateral Movement Chain: From IT Foothold to OT Impact

Understanding why segmentation matters requires tracing the actual attack path that LOTL adversaries follow. The Dragos 2026 report found that 73% of all incident response cases involved compromised VPN or jumphost credentials as the initial IT-to-OT pivot point. That number has been consistent across multiple years of Dragos reporting, which tells us the industry still hasn't solved this problem.

Here's how the chain typically unfolds, mapped to the MITRE ATT&CK for ICS framework:

Step 1: IT compromise via commodity means. Phishing, exploited VPN appliance, or compromised third-party credentials. The Dragos report noted that engineering firms, system integrators, and managed service providers became primary targets in 2025 because of their trusted multi-environment access.

Step 2: Credential harvesting and Active Directory compromise. Attackers extract the NTDS.dit database or use Kerberoasting to obtain service account credentials. Volt Typhoon, the PRC-sponsored group that CISA confirmed had maintained access to U.S. critical infrastructure for over five years, achieved full domain compromise in multiple environments using exactly this approach.

Step 3: Pivot to OT via shared infrastructure. Dragos found that 17% of assessed organizations had a shared domain architecture between IT and OT. But even organizations with separate domains often share jump servers, VPN concentrators, or historian servers that bridge both networks. These dual-homed systems become the lateral movement highway.

Step 4: OT reconnaissance using native protocols. Once on the control network, attackers enumerate assets using the same protocols that operators use daily. KAMACITE demonstrated this in 2025, systematically scanning HMIs, variable frequency drives, meters, and remote gateways to map entire control loops. The Dragos report noted they were specifically investigating "what operational conditions would trigger process shutdowns."

Step 5: Impact or persistence. The adversary either executes their objective (process disruption, data theft, pre-positioning for future conflict) or embeds themselves for long-term access. Both outcomes are enabled by the unrestricted lateral communication that flat OT networks allow.

Every step after the initial IT compromise relies on one thing: the ability to move freely between network segments and between devices within those segments. That is the architectural failure that segmentation addresses.

VLANs Are Not Microsegmentation (and They Won't Stop LOTL)

Most OT environments I've assessed have some form of network segmentation in place. They have VLANs separating the corporate network from the plant floor. They may have firewalls at the Purdue Model Level 3/3.5 boundary. Some have implemented a DMZ between IT and OT per IEC 62443 zone and conduit requirements.

This is necessary. It isn't sufficient.

The reality is that VLANs create coarse network boundaries. Within a VLAN, every device can communicate with every other device. A compromised engineering workstation on VLAN 100 can reach every PLC, every HMI, and every I/O module on that same VLAN using native OT protocols. The VLAN boundary does nothing to constrain intra-zone lateral movement, which is precisely how LOTL attackers operate once they've crossed the IT/OT boundary.

The Purdue Model was designed in the 1990s as a reference architecture for separating enterprise and control systems. It defines hierarchical levels (0 through 5) with trust boundaries between them. In practice, modern OT environments have eroded these boundaries through cloud connectivity, remote access requirements, IIoT deployments, and IT/OT convergence initiatives. The model remains useful as a conceptual framework, but treating it as a security architecture without per-device enforcement is a recipe for the exact lateral movement patterns Dragos documented.

IEC 62443, the international standard for industrial automation security, explicitly requires zones and conduits with defined security levels. But most implementations stop at the zone level (groups of devices sharing common security requirements) without enforcing conduit-level communication rules between individual assets. The standard calls for this granularity. The implementations rarely deliver it.

Here's the gap: a VLAN-based zone might contain 200 devices. Within that zone, the HMI that an operator uses to monitor a reactor vessel can communicate with the PLC controlling a completely unrelated packaging line. There is no operational reason for that communication. But without device-level policy enforcement, there is no way to prevent it. And that unnecessary communication path is exactly what a LOTL adversary will use.

Identity-Based Microsegmentation as the Architectural Answer

If the problem is unrestricted device-to-device communication within network zones, then the solution must operate at the device level. This is where microsegmentation fundamentally differs from traditional OT network segmentation.

Instead of defining broad network boundaries and hoping devices stay within their lanes, identity-based microsegmentation builds policy around what each device actually is: its manufacturer, model, firmware version, function, and communication profile. A Siemens S7-1500 PLC running a water treatment process should communicate with its associated HMI, its historian, and the engineering workstation authorized for its maintenance. It should not communicate with the building management system, the guest WiFi network, or PLCs in a different process cell.

This approach directly addresses the LOTL problem because it constrains what legitimate protocol commands can traverse the network, regardless of whether the source is a trusted device or a compromised one. Even if an attacker gains control of an engineering workstation and uses native OPC-UA commands to attempt reconnaissance, device-level policies prevent that workstation from reaching assets outside its authorized communication group.

For OT environments specifically, effective microsegmentation must meet several requirements:

• Agentless enforcement. You can't install agents on PLCs, safety controllers, or legacy HMIs. Policy must be enforced at the network layer using existing switching infrastructure.
• Protocol-aware policy. Policies need to account for the specific OT protocols in use (Modbus, EtherNet/IP, OPC-UA) and the communication patterns associated with each device's operational role.
• Non-disruptive deployment. OT environments can't tolerate network outages for security tool deployment. Any solution must operate in a monitoring mode before enforcement, validated by operations teams familiar with the process.
• IEC 62443 alignment. Microsegmentation policies should map directly to IEC 62443 zones and conduits, enabling compliance while actually delivering the per-device control the standard envisions.

Limitations and Considerations

I want to be honest about what microsegmentation does and doesn't solve. It constrains lateral movement and limits blast radius. It doesn't detect the initial compromise. It doesn't replace OT-specific network monitoring platforms like Dragos, Claroty, or Nozomi Networks, which provide protocol-level anomaly detection and threat intelligence. And it requires accurate asset discovery and classification as a prerequisite, because you can't write effective device-level policies if you don't know what devices exist on your network.

Microsegmentation also requires organizational alignment between IT, OT, and security teams. Policies that restrict an engineering workstation's communication scope will affect how maintenance technicians do their work. Those conversations need to happen before enforcement, not after.

What OT Security Leaders Should Do Now

The Dragos 2026 findings point to specific, actionable steps. Not every organization will implement all of these immediately, but each one reduces the attack surface available to these adversaries.

1. Audit your IT/OT boundary for shared credentials and infrastructure. Dragos found that 73% of IR cases involved compromised VPN or jumphost credentials. Identify every system that bridges IT and OT: jump servers, historians, remote access platforms, shared Active Directory domains. Treat each one as a potential pivot point and apply the principle of least privilege to every account that crosses that boundary.

2. Map your actual device communication patterns before writing policy. Microsegmentation works when policies reflect operational reality. Spend 30 to 60 days in a monitoring-only mode, building a baseline of which devices communicate with which other devices, on which protocols, and at what frequency. This baseline becomes your policy foundation. The SANS analysis of the Dragos report emphasized that "architecture determines whether incidents stay contained." You need to understand your architecture before you can improve it.

3. Implement device-level segmentation within OT zones, not just between them. Move beyond VLAN-based segmentation to per-device policies that constrain lateral movement within control network segments. Prioritize your highest-consequence assets first: safety instrumented systems, critical process controllers, and any device that directly affects physical safety or environmental compliance. This is where the Dragos finding on intra-zone movement applies most urgently. Zero Trust microsegmentation provides the architectural foundation for this level of granular control.

4. Integrate OT asset discovery with your segmentation platform. The SANS 2025 ICS/OT Survey indicated that asset visibility investment significantly outpaced segmentation investment, with roughly half of organizations prioritizing visibility while fewer than a third invested in segmentation. These capabilities need to work together. Network segmentation without asset intelligence is guesswork. Asset visibility without enforcement is a list of problems you can see but not solve.

The Bigger Picture

The Dragos 2026 report makes clear that adversaries are operating at a level of OT sophistication that renders perimeter-only and detection-only strategies insufficient. Groups like KAMACITE aren't scanning randomly. They are mapping control loops, understanding process dependencies, and identifying the specific conditions that would cause maximum operational disruption.

The defenders who will contain these threats are the ones building architectures where even a fully compromised, credential-equipped adversary can't freely traverse the control network. That is the promise of identity-based microsegmentation: not that it prevents compromise, but that it limits the blast radius of compromise to something an organization can survive.

The protocols won't change. Modbus won't gain authentication. EtherNet/IP won't encrypt its payloads tomorrow. The adversaries who understand these protocols will continue to live off the land. The question is whether your network architecture forces them to live in a very small house.

Frequently Asked Questions About Living Off the Land Attacks in OT

What is a living-off-the-land attack in OT environments?

A living-off-the-land (LOTL) attack in OT environments occurs when adversaries use legitimate industrial protocols and native system tools to conduct reconnaissance, move laterally, and achieve their objectives without deploying custom malware. In IT, LOTL typically means abusing PowerShell or WMI. In OT, it means using protocols like Modbus/TCP, OPC-UA, EtherNet/IP, and DNP3 to issue commands that PLCs and HMIs execute as valid instructions. Because these protocols lack authentication by design, a malicious command from a compromised engineering workstation is indistinguishable from a legitimate one. The Dragos 2026 report found that 56% of penetration tests abused these techniques without triggering any detection alerts.

Why can't endpoint detection stop living-off-the-land attacks in operational technology?

Endpoint detection and response (EDR) tools require software agents installed on each device. Most OT assets, including PLCs, safety controllers, RTUs, and legacy HMIs, can't run agent software due to hardware limitations, real-time processing requirements, or vendor certification restrictions. Even on the Windows-based engineering workstations where agents can be deployed, the legitimate administrative activities (firmware uploads, remote HMI access, configuration changes) generate telemetry that is operationally identical to attacker behavior. The SANS analysis of the Dragos 2026 findings concluded that "visibility gaps, not zero-days, drive most failures" in OT security. Protocol-level monitoring from OT security platforms like Dragos, Claroty, or Nozomi Networks helps detect anomalies, but detection alone can't prevent the lateral movement that these attacks depend on.

How does microsegmentation defend against living-off-the-land attacks?

Microsegmentation constrains these attacks by enforcing device-level communication policies that restrict which assets can talk to which other assets, regardless of the protocol used. Even if an attacker compromises an engineering workstation and issues perfectly valid OPC-UA commands, microsegmentation policies prevent that workstation from communicating with devices outside its authorized scope. This limits the adversary's ability to enumerate assets, map control loops, or pivot from one process area to another. Unlike detection-based approaches that try to distinguish malicious commands from legitimate ones (an extremely difficult task with unauthenticated OT protocols), microsegmentation reduces the attack surface by eliminating unnecessary communication paths. For IEC 62443 compliance, this approach maps directly to the zones and conduits model, enforcing conduit-level restrictions that most VLAN-based implementations fail to deliver.

What are the three new OT threat groups identified in the Dragos 2026 report?

The Dragos 2026 OT Cybersecurity Year in Review identified three new threat groups: AZURITE, PYROXENE, and SYLVANITE. AZURITE targets engineering workstations to exfiltrate operational data including network diagrams and alarm configurations, with technical overlaps to Flax Typhoon. PYROXENE conducts multi-year supply chain campaigns using social engineering (including fake LinkedIn recruiter profiles) and deployed custom wiper malware in June 2025. SYLVANITE functions as an initial access broker, rapidly weaponizing vulnerabilities in edge devices and handing off established footholds to groups like VOLTZITE for deeper OT intrusion. Together with the 23 previously tracked groups, Dragos now monitors 26 threat groups targeting operational technology, and the report emphasizes their increasing coordination as interconnected ecosystems rather than isolated actors.

Further Reading

• Microsegmentation: The Essential Guide to Network Security
• Understanding and Preventing Lateral Movement: A Strategic Guide
• IEC 62443 Network Segmentation Requirements and Changes
• How to Stop Lateral Movement in Ransomware Attacks
• The Hidden Highway: Ransomware and Lateral Movement in Critical Infrastructure
• Leading Vendors for Securing OT and Industrial Control Systems in 2026
• Network Segmentation: The Key to Stopping Lateral Movement
• Preventing Ransomware Through Microsegmentation
• Elisity for Industrial and OT Environments
• Elisity + Claroty Integration
• Elisity + Nozomi Networks Integration