Key takeaways
- The data historian is dual-homed by design: it must talk to both the IT network and the OT DMZ, which makes it a natural pivot for any attacker who lands on the IT side.
- Credential reuse is the mechanism that crosses the boundary. An account valid on corporate Active Directory is often valid on the historian, with no additional authentication barrier at the zone edge.
- Discovery on the OT side can be entirely passive: reading process tags from the historian database reveals controller addresses, protocol versions and plant topology without sending a single packet to the control network.
- Zone enforcement at the historian is the control that breaks this chain. A historian that accepts connections only from named OT processes removes the pivot without touching operations.
- An OT/ICS pentest that stops at the IT-OT boundary misses the most common path into the control network.
What the Purdue model separates, and where the historian sits
The Purdue Enterprise Reference Architecture divides an industrial site into numbered levels. Level 0 and Level 1 are the physical process and the controllers that run it: programmable logic controllers (PLCs), remote terminal units (RTUs) and field instruments. Level 2 is the supervisory layer: SCADA servers, human-machine interfaces (HMIs) and engineering workstations that download control logic. Levels 3 and above cross into IT: manufacturing operations management, plant historians and the corporate network.
The data historian lives at the boundary between Level 3 and the OT DMZ. Its job is to collect time-series process data from supervisory systems and make it available to business applications, reporting tools and remote dashboards on the IT side. That job requires two network interfaces: one facing the OT DMZ, and one facing the corporate network. No other device on most sites has both. That makes it the most common pivot in IT-to-OT attacks.
An OT/ICS pentest covers both sides of this boundary: the corporate network path in and the control network reachable once the historian is compromised. Understanding this pivot separates a pentest that finds the real exposure from one that stops at the firewall log. The same boundary architecture also appears in infrastructure pentests where the scope extends from corporate hosts into industrial segments.
In
Phishing foothold
Corporate workstation, IT zone
Credential collection
LSASS dump or Kerberos tickets
Through
Historian discovery
Dual-homed host, two NICs confirmed
Zone boundary crossing
IT credentials valid on historian
Supervisory host mapping
OT DMZ reachable from historian
Out
Process data collection
Tag reads from historian database
Controller topology
PLC addresses inferred from tags
The attack chain from phishing inbox to control network
The chain starts where most breaches start: a phishing email delivers a payload to a corporate host. The attacker has a foothold in the IT zone, subject to all the monitoring and controls that apply there. Nothing unusual has happened yet.
Network discovery from the compromised host reveals the historian. It appears as a Windows server with two active network interfaces. One routes to the corporate VLAN. The other routes to a subnet populated with addresses that answer on ports 102, 502 and 4840: Siemens S7, Modbus and OPC-UA. The historian is the door.
The credential that opens it is already in memory on the corporate host. Domain credentials collected from LSASS, or a Kerberos ticket for a service account that also runs the historian data connector, are presented at the historian RDP or SMB port. The historian accepts them. The attacker has a session inside the OT DMZ. No additional authentication was required at the zone edge.
From that session, the attacker reads process data directly from the historian database. Tag names encode the plant topology: a tag named SITE1.UNIT3.PLC2.T_FEED names a controller, a unit and a measurement point. No scan is needed. The historian's own data reveals the control network below it. That topology enables the techniques described in the companion article on engineering workstation to PLC logic tampering.
Discovery and credential collection on the IT side
From the initial foothold, the attacker runs a port scan toward the subnets visible from the corporate host. The historian answers on port 445 (SMB), 3389 (RDP) and 4840 (OPC-UA). The OPC-UA port identifies the machine as an industrial data broker rather than a standard IT server. MITRE ATT&CK for ICS tracks the use of existing remote services as External Remote Services (T0822).
Credential collection follows. LSASS memory contains plaintext credentials or Kerberos tickets for accounts that have recently authenticated on the workstation. A service account that runs a historian data connector may have logged on interactively at some point, leaving its credential in the cache. impacket-secretsdump or a direct LSASS dump extracts it. The technique is documented as Valid Accounts (T0859) in the ICS matrix. The same credential dumping steps appear in assumed breach exercises when the granted foothold is a corporate workstation rather than an OT host.
# Discover hosts with OPC-UA and OT-adjacent ports from the corporate VLAN
nmap -Pn -p 102,502,4840,3389,445 192.168.10.0/24
# Historian found at 192.168.10.47
# PORT STATE SERVICE
# 102/tcp open iso-tsap # Siemens S7
# 445/tcp open microsoft-ds
# 3389/tcp open ms-wbt-server
# 4840/tcp open opcua # OPC Unified Architecture# Extract cached credentials including the historian service account
impacket-secretsdump -just-dc-user svc_historian DOMAIN/admin:[email protected]
# [*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
# DOMAIN\svc_historian:1105:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::
# [*] Kerberos keys grabbed
# Account is a domain member; RDP to historian succeeds with these credentialsWhat the attacker finds inside the OT DMZ
With credentials in hand, the attacker opens a Remote Desktop session to the historian. The historian runs Windows Server and is joined to the same domain as the corporate network. The session is indistinguishable from a legitimate administrator connection. The historian's second NIC shows a route to the OT DMZ subnet: 10.100.0.0/24.
A light scan of the OT DMZ from the historian session reveals SCADA servers, HMI stations and jump hosts, all reachable without a firewall prompt. The historian is inside the OT perimeter by design; its second interface has LAN access, not filtered access. That reachability makes Modbus/TCP unauthenticated command injection a follow-on step once a PLC address is known.
Before scanning, the attacker reads the historian's own process database. Products such as OSIsoft PI store tag names that encode the plant hierarchy. A single query returns hundreds of controller addresses, measurement names and site codes without sending a single packet to the control network. Discovery is passive and silent from the OT monitoring perspective.
The NIST SP 800-82 Guide to OT Security classifies this exposure under unprotected remote access paths. The guide's recommended control is strict zone-to-zone firewall policy with application-layer inspection, not simply VLAN separation that the historian's physical routing already bypasses.
# From an RDP session on the historian (10.100.0.5)
# Scan the OT DMZ for supervisory hosts
nmap -Pn -p 102,502,20000,44818 10.100.0.0/24
# Results (abbreviated)
# 10.100.0.10 open iso-tsap (S7) # Siemens PLC
# 10.100.0.11 open dnp3 # RTU
# 10.100.0.20 open ms-wbt-server # HMI workstation
# 10.100.0.50 open ethernetip-1 # Allen-Bradley controller# Query an OSIsoft PI historian for tag names
# Read-only; no additional authentication beyond the Windows session
piconfig.exe
> @table pibatch
> @select tag, descriptor, instrumenttag
> @outputto C:\tags.csv
> @exit
# tags.csv (excerpt)
# SITE1.UNIT3.PLC2.T_FEED, Feed temperature Unit 3, 10.100.0.10:slot0.AI1
# SITE1.UNIT3.PLC2.P_PUMP, Pump pressure Unit 3, 10.100.0.10:slot0.AI2
# Controller address 10.100.0.10 recovered without scanning the control networkThe controls that break this chain
The chain has three links: network reachability, credential reuse and historian access from an administrative session. Each can be cut independently, and cutting any one of them stops the pivot.
Zone enforcement at the historian is the most effective single control. The historian's OT-facing interface should accept connections only from named OT processes: the SCADA server that writes tag data, the DCS historian connector and nothing else. An IT management host opening a connection to the historian OT interface should fail at the firewall, not at the application. An OT/ICS pentest tests exactly this: not whether the firewall rule exists in policy, but whether a connection actually fails when the rule should block it. The scope and safety rules for running that test are covered in the buying guide for OT/ICS pentests.
Credential separation removes the second link. A service account that runs the historian data connector should have no domain privileges and no interactive logon right. Its password should be unrelated to any IT account, stored in a vault and rotated. An account that is valid only on the historian and only for its connector process cannot be collected from an IT LSASS dump and reused elsewhere.
RDP and SMB to the historian should not be reachable from the IT zone. If those ports are open to the corporate network, the historian is an IT server for exploitation purposes, whatever zone policy says on paper. The signals each link produces during a live test are detailed in the article on what OT monitoring should catch during an ICS pentest. What the pentest report should say about these findings is covered in what an OT/ICS pentest report must contain.
| Chain link | Breaking control | Verification test |
|---|---|---|
| Historian reachable from IT VLAN | Firewall allows OT-facing traffic only from named OT sources | Attempt connection from IT management host; connection should be refused |
| IT-side credential valid on historian | Separate service account, no IT domain membership, vault-managed password | Attempt to authenticate with an IT domain account; authentication should fail |
| RDP or SMB open to IT zone | Historian management ports bound to OT management VLAN only | Port scan historian from corporate VLAN; ports 445 and 3389 should not answer |
| Process tags expose controller addresses | Tag namespace access controlled by role; IT users receive aggregated data only | Query tag database as an IT user; raw instrument tags and PLC addresses should not be visible |
IT-to-OT pivots and the UAE industrial security landscape
The UAE operates critical infrastructure across energy, water, utilities and manufacturing in both Abu Dhabi and Dubai. Many of these sites run a Purdue-style architecture with a corporate IT network, a data historian layer and a control network below it. The historian pivot described in this article is not a theoretical scenario: it reflects the architecture present on sites across both emirates, and the zone enforcement gaps that enable it appear wherever IT and OT share an authentication domain.
In Abu Dhabi, the ADHICS framework published by the Department of Health applies to healthcare facilities, some of which operate building management and medical device networks that share similar boundary characteristics to industrial sites. The UAE Information Assurance Regulation, published federally by TDRA, applies to government entities and their suppliers and requires network segmentation controls and access management that directly address the credential reuse and zone boundary gaps the historian pivot relies on.
In Dubai, the DESC Information Security Regulation applies to Dubai government entities and their technology suppliers. DESC requires documented zone boundary controls, access reviews and incident detection capability. A historian that authenticates IT domain accounts without a separate OT-side credential policy would not satisfy these requirements under a reasonable reading of the standard.
CBUAE regulations apply to banks and financial institutions, some of which operate treasury and payment processing systems alongside building and facilities infrastructure. Where IT and OT share a domain, the historian pivot is in scope for the security testing those regulations ask for.
An OT/ICS pentest that walks this chain produces evidence relevant to all four regulatory frameworks: network segmentation testing, access control verification and lateral movement path documentation are outputs that map directly to the control categories each regime defines.
Frequently asked questions
What is a data historian in an industrial control system?
A data historian is a server that collects time-series process data from SCADA or DCS systems and stores it for reporting, analytics and business integration. It sits at the boundary between the OT network and the IT network, with connections to both. Because it bridges the two zones, it is the most common lateral movement path in IT-to-OT attacks.
What is the Purdue model in OT security?
The Purdue Enterprise Reference Architecture is a layered network model for industrial control systems. It separates the physical process (Levels 0 and 1), the supervisory control layer (Level 2), manufacturing operations (Level 3) and the corporate network (Levels 4 and 5). The model recommends strict zone boundaries between each level to limit the blast radius of a compromise in any one zone.
How does credential reuse across IT and OT zones enable this attack?
When a service account or domain account that exists on the corporate Active Directory is also configured on the historian, an attacker who collects that credential on the IT side can use it to authenticate to the historian without any additional barrier. The historian treats it as a valid authentication. MITRE ATT&CK for ICS documents this under Valid Accounts (T0859).
How does an IT-to-OT pivot via the historian differ from a direct OT network attack?
A direct OT attack requires a foothold already inside the OT network, typically through physical access or a compromised OT-facing connection. An IT-to-OT pivot starts from a standard phishing foothold on a corporate host and uses the historian as a bridge. It requires no physical access and no prior OT compromise, which makes it accessible to any attacker who can land a phishing payload.
Can the attack be detected from the OT side?
Reading process tags from the historian database generates no OT-side traffic, making it invisible to any monitoring attached to the control network. A connection from the historian to a supervisory host from an unexpected source account would appear in Windows event logs on the supervisory host, but only if those logs are collected and forwarded. Network flow data showing IT-to-historian and historian-to-OT-DMZ connections in the same session window is the most reliable indicator.
What OT protocols are visible once inside the OT DMZ?
The most common are Modbus/TCP (port 502), Siemens S7 (port 102), DNP3 (port 20000), EtherNet/IP (port 44818) and OPC-UA (port 4840). These protocols carry engineering-grade commands with no authentication, so a host that can reach a controller port can read its process values and, depending on the protocol, write to output registers.
What is MITRE ATT&CK for ICS and how does it relate to this technique?
MITRE ATT&CK for ICS is the extension of the ATT&CK framework to industrial control systems. It documents tactics and techniques specific to OT environments, including Initial Access, Discovery, Lateral Movement and Inhibit Response Function. The techniques T0822 (External Remote Services) and T0859 (Valid Accounts) both apply directly to the historian pivot chain.
What does an OT/ICS pentest actually verify about zone boundaries?
An OT/ICS pentest tests whether zone boundary controls work in practice, not in policy. This means attempting connections from IT hosts to historian ports, trying IT-side credentials on historian and OT-facing systems, and checking whether supervisory hosts are reachable from the IT zone through any path. A firewall rule that exists in a configuration document but is overridden by a standing exception is exactly the kind of gap the test surfaces.
How does the IT-to-OT historian pivot relate to the engineering workstation attack path?
The historian pivot delivers control network access. The engineering workstation attack is what comes next. Once a supervisory host is reached from the OT DMZ, an engineering workstation on the same network segment can be targeted to modify control logic on a PLC. The two techniques are sequential: historian pivot to reach the network, engineering workstation compromise to affect the process.
