Closing the Attack Paths That Lead to OT

For years, OT security has meant guarding the plant floor as a fortified island. That meant hardening PLCs, segmenting the control networks, and treating the corporate network as a separate domain managed by a different team with a different budget. Unfortunately, the concept of the air-gapped OT island is obsolete. It is no longer a fortified position but a destination.

Proving that an attacker can or cannot reach the operational boundary is the highest-priority risk indicator and can prove where exploitable risk exists. The most important part of securing the plant floor is securing every pathway that leads to it.

Legacy OT: A Permanent Vulnerability

Most of the equipment running the world’s plants was designed for a 30-year lifecycle and one critical priority: availability. These devices are still in production and likely will be a decade from now. However, they were never designed to be secure.

The Windows hosts that sit alongside the controllers are no better. Engineering workstations, HMIs, and servers still run on legacy Windows operating systems that left mainstream Microsoft support a decade ago. Updating them to a newer OS would require a production outage.

At the same time, the attack surface is expanding with IoT and IIoT devices that frequently have weak default security that allows attackers to gain a persistent foothold inside the corporate network and use it as a beachhead for lateral movement toward critical OT systems.

Key takeaway: Legacy devices will stay vulnerable while new technology is flooding the plant floor and broadening the attack surface by introducing new connectivity.

Attackers Need IT

Every consequential OT attack in the public record has had an IT-side phase, and the majority of the attacker's effort was there:

• Stuxnet ended at Siemens S7-315 and S7-417 controllers driving centrifuge cascades, but it arrived there through engineering workstations, USB media, and Windows hosts running Step 7.
• The Colonial Pipeline attack began as an IT compromise, where a single credential on a forgotten VPN account caused a precautionary OT shutdown without the attackers ever needing to touch a controller.
• Incontroller is a good example of where today’s threats are heading. The framework was deliberately designed so that an operator without deep OT expertise could create impact across multiple vendors, multiple protocols, and multiple controller families.

Attackers need IT, because that is where the foothold is established, the credentials are harvested, and the lateral movement is mapped. If the IT and network infrastructure that touches your OT is not adversary-tested, your OT is not adversary-tested.

Key takeaway: Attackers will use AI to chain vulnerabilities, security gaps, and misconfigurations into composite kill chains at scale. Your environments must be validated at the same scale, with the same kind of tooling, on a continuous cadence. 

What Does an IT-to-OT Attack Path Actually Look Like?

The chain below is a real-world example from a recent engagement and includes four parallel paths originating from a single IT foothold:

• Step 1—initial access: A vulnerability in a web app results in a remote code execution (RCE) that leads to persistence, harvested credentials, and a session token from an IT systems administrator in the corporate domain. 
• Step 2—discovery: The attacker enumerates Active Directory and the local host. AD reveals the usual: shadow privileged groups, stale service accounts, OT Engineering OUs. The local host reveals more and from here, four separate paths into OT present themselves:
  
  • Path 1—credentials in PowerShell history: The compromised user’s ConsoleHost_history.txt file holds the last 4,096 commands the admin ran, including a PSSession to an engineering workstation at Level 3 with the credential passed in plain text. A nearby scheduled task runs nightly with a hardcoded historian service account password embedded in the script. The attacker has two ways into OT before leaving the corporate desktop.
  • Path 2—Corporate password vault: The same administrator has access to a shared PAM vault titled Plant Operations. Inside are local administrator credentials for the Level 3.5 jump hosts, the historian SA account, and the vendor remote access account for the SEL relays. 
  • Path 3—OT infrastructure in the IT cloud: The organization’s posture is that OT does not touch the cloud. The Azure tenant contains an Azure Virtual Desktop pool tagged OT-Engineering-Remote, three historian replica VMs in a subscription owned by Plant IT, and a SCADA dashboard front end hosted in an App Service that proxies read queries into the control network through a “monitoring-only” tunnel. The attacker, who now holds Reader on the tenant via the compromised admin’s role, walks through all of it from a browser.
  • Path 4—Shared EDR tenant: Both IT and OT endpoints are managed in a single EDR console. The compromised admin holds a role with RemoteOps enabled. The attacker opens a remote shell to a Level 3.5 jump host, a Level 3 engineering workstation, and an HMI from the EDR console, all logged as legitimate administrative activity, and all without traversing a single network control. The compensating control was rule-based and the attacker obeyed the rules.
• Step 3—The line that should not be crossed: Each of the four paths terminates at an asset with direct authority over a PLC where the attacker can read logic, modify it, or push unauthorized changes over any number of proprietary protocols. The trust model assumes only engineers reach this segment, and the segmentation that was supposed to enforce that assumption broke four different times, in four different IT systems, before the attacker ever touched OT.

Key takeaway: In this example the four clear paths are IT problems. In this particular engagement, all four were leveraged and looked like legitimate administrative activity. 

The Armadin Advantage Is Agentic Path Validation

Historically, organizations have struggled to validate IT/OT boundaries, because traditional tools and engagements lack the breadth and persistence to map complex lateral movement. A point-in-time penetration test finds one path, but an adversary finds the other paths on a different day.

Armadin changes that math. By fusing agentic AI with elite human oversight, including operators with backgrounds at Mandiant and Fortune 100 red teams, we continuously pressure-test these access pathways with precision and at scale:

• Path-based offensive testing: We identify the non-obvious routes through enterprise, cloud, and identity systems that could allow a threat actor to reach the operational boundary. Where a traditional engagement reports a single successful chain, the Armadin platform discovers the parallel paths an adversary would also find, the ones that get exercised after the first chain is closed.
• Continuous validation: The threat landscape shifts daily. New credentials are exposed, new IIoT connections come online, and new trust relationships are inherited from acquisitions. The Armadin attacker continuously validates that segmentation, identity hygiene, and IDMZ controls remain intact against current adversary tradecraft, including the AI-driven attacker techniques whose surface area grows by the week.
• Do-no-harm approach: This principle ensures that the Armadin attacker focuses on the right scope: IT-side validation. By rigorously testing IT environments, we identify and eliminate the attack paths that lead to OT, delivering high-confidence assurance with zero exposure to the production OT environment. This approach, which keeps controller writes, logic changes, HMI manipulation, and all interactions with safety-instrumented systems entirely off-limits, is critical to protecting production uptime and overall safety of operations.
• Severance over enumeration: A list of 50 IT findings is not actionable. Armadin highlights what vulnerabilities are actually exploitable. While dozens of findings might exist, there might only be one that leads to a fully exploitable attack path that allows an attacker to access critical systems. By focusing on this critical exploitable risk and ensuring a human validates that findings are not false positives, we lead our recommendations with architectural changes that sever the largest fraction of validated and adjacent attack paths.

Key takeaway: The output of an engagement should be a prioritized list of architectural changes that sever multiple chains at once, scored by exploitable rather than theoretical risk. Treat any IT/OT conduit you cannot describe in one sentence (purpose, controlling authority, observable use, severance procedure) as a finding in itself.

Stay Ahead of Whatever Threats May Come

While the detect-and-respond approach was a sufficient posture for an era in which adversary effort was a scarce resource, that effort scales quickly in an AI-accelerated era. The only durable response is to proactively prove your defenses by closing the paths an attacker needs.

At Armadin we don’t just find vulnerabilities. We prove and close the exploitable attack paths that actually matter. Learn how today.