BLOG

Top 5 Cyber Threats Targeting SCADA Systems in Oil & Gas Distribution

SCADA systems in oil and gas distribution perform a function that no other technology can substitute: they provide the centralized visibility and control that makes it possible for a small team of operators to manage hundreds of miles of pipeline, dozens of compressor stations, and thousands of field devices from a single control room. When a SCADA system is compromised, operators lose that visibility. When it is actively manipulated, the consequences extend beyond IT and into the physical world.

The threat actors targeting SCADA systems in oil and gas distribution are not primarily motivated by data theft. They are motivated by disruption - the ability to halt product flow, create pressure anomalies, trigger or suppress safety shutdowns, or deny operators the visibility they need to operate safely. Understanding the specific threats that are being used against these systems in 2025 and 2026 is the starting point for building defenses that address the actual risk.

This post covers the five cyber threats most actively documented against SCADA systems in oil and gas distribution. For each threat, it explains how the attack works in the context of a distribution SCADA environment, which part of the SCADA architecture is targeted, and the specific controls that address it.

Dragos documented 1,693 ransomware attacks targeting industrial organizations in 2024 - an 87% increase over 2023

with oil and gas distribution among the three most targeted subsectors. In the majority of confirmed OT incidents reviewed by Dragos, the SCADA server tier was the primary target once the adversary achieved IT network access - not the field devices. Protecting the SCADA server infrastructure is the highest-leverage security investment in distribution operations.

Source: Dragos 2025 OT/ICS Cybersecurity Year in Review

Overview: The 5 SCADA Threats in Oil & Gas Distribution

#	Threat	Primary SCADA Target	Operational Impact if Successful
1	Ransomware deployed to SCADA server infrastructure	Historian servers, SCADA servers, engineering workstations	Loss of SCADA visibility; forced manual operation or shutdown
2	Remote access exploitation via vendor VPN	SCADA HMI, engineering software, RTU configuration interfaces	Unauthorized control of field devices; manipulation of process setpoints
3	Industrial protocol manipulation (Modbus, DNP3)	RTUs, PLCs, and field devices communicating with SCADA	False data injection, unauthorized commands, sensor spoofing
4	Supply chain compromise via SCADA software updates	SCADA platform software, historian, engineering tools	Persistent malware with control capabilities embedded in production systems
5	Nation-state pre-positioning for infrastructure disruption	Full SCADA environment from field to control room	Long-term dwell with capability to cause physical disruption on demand

Threat 1: Ransomware Deployed to SCADA Server Infrastructure

1.1 How This Attack Works in a Distribution Environment

Ransomware operators targeting oil and gas distribution do not need to compromise SCADA protocols or OT-specific systems to cause an operational shutdown. In the majority of confirmed cases, they gain initial access through the IT network - via a phishing email, a compromised VPN credential, or a vulnerable internet-facing service - and then use lateral movement techniques to reach the OT environment through the IT/OT boundary.

The SCADA historian server is typically the first OT asset reached through this pathway. Historians sit at the IT/OT boundary: they pull operational data from the SCADA system and make it available to corporate IT systems. A historian server that is accessible from the IT network and has a network path to the SCADA server tier provides a direct bridge into OT for an adversary who has compromised the IT environment.

Once ransomware is deployed to the historian and SCADA servers, operators lose the real-time visibility and remote control capability that SCADA provides. Even if field devices are still operating normally, the loss of SCADA monitoring forces operations into manual mode or triggers a precautionary shutdown - exactly the operational disruption the attackers intend.

1.2 Why Distribution Operations Are Particularly Exposed

Pipeline distribution operations have a specific vulnerability to SCADA availability loss that upstream operations do not share to the same degree: product in transit. A crude production facility that loses SCADA can halt injection and wait for systems to be restored. A distribution pipeline carrying refined products to downstream customers under delivery commitments faces a more complex operational decision when SCADA goes down - one that the Colonial Pipeline operator had to make in May 2021.

1.3 Controls That Address This Threat

Enforced IT/OT segmentation with Industrial DMZ: The historian and all data flows between IT and OT must pass through a controlled DMZ. No direct IP connectivity between IT endpoints and SCADA servers.
SCADA server backups stored offline and tested regularly: Ransomware cannot encrypt backups that are not network-accessible. Offline backups with documented and tested restoration procedures are the primary resilience control.
OT network monitoring at the SCADA tier: Anomalous connections to SCADA servers - new source IP addresses, unusual authentication patterns, unexpected file access - are detectable before ransomware executes if monitoring is in place.
Separate identity infrastructure for OT: Shared Active Directory between IT and OT means a compromised domain administrator credential provides access to OT-connected systems. Separate OT identity infrastructure eliminates this lateral movement pathway.

Operational Reality

The decision to halt pipeline operations when the IT network is compromised is not a cybersecurity decision. It is an operational risk decision that has financial, contractual, and safety implications. Operators who have invested in a verifiable IT/OT boundary - one they can confidently assert is secure during an active IT incident - do not face the forced choice between operating blind and shutting down. That confidence is the operational value of OT security investment.

Threat 2: Remote Access Exploitation via Vendor VPN

2.1 How This Attack Works in a Distribution Environment

Oil and gas distribution SCADA environments depend heavily on remote access. Compressor station vendors, SCADA platform integrators, flow computer calibration services, and pipeline integrity management firms all require periodic remote access to OT systems. In most distribution environments, this access is implemented as persistent site-to-site VPN connections that remain active between maintenance events, shared among multiple vendor personnel, and managed outside any formal identity governance program.

Adversaries who target vendor organizations - which are typically smaller companies with less security maturity than the asset owners they service - can harvest VPN credentials through phishing or credential stuffing and use them to access distribution SCADA environments directly. Because the connection arrives over an authorized VPN pathway with valid credentials, it does not trigger perimeter-based detection controls.

2.2 The Compressor Station Remote Access Problem

Compressor stations in gas distribution pipelines represent a specific concentration of remote access risk. A single compressor station may have remote access connections for the SCADA integrator, the compressor OEM, the gas measurement vendor, the PLC programmer, and the pipeline control center - each potentially managed as a separate persistent VPN or remote desktop session. The aggregate remote access attack surface at a single compressor station can easily exceed a dozen independent connection pathways, most of which are not actively monitored.

2.3 Controls That Address This Threat

Centralized secure access gateway replacing all persistent vendor VPNs: Every remote session to SCADA and field systems is brokered through a single gateway that enforces MFA, scopes access to specific assets, and records every session.
Just-in-time access provisioning: Vendor access is activated for a defined time window when a maintenance event is scheduled and automatically revoked when the session ends. No standing access between events.
Vendor access inventory and review: Conduct a full audit of all active remote access pathways to OT systems. Terminate any connections associated with vendors who are no longer actively engaged. This exercise alone typically identifies multiple access pathways that should not exist.
TSA Security Directive compliance for designated operators: TSA Directives mandate MFA for remote access to OT systems and network segmentation between IT and OT. Operators who have implemented these controls as part of TSA compliance have addressed the most critical remote access vulnerabilities.

Threat 3: Industrial Protocol Manipulation - Modbus, DNP3, and ICCP

3.1 How This Attack Works in a Distribution Environment

SCADA systems in oil and gas distribution communicate with field devices using industrial protocols that were designed in an era when the assumption of network isolation made authentication and encryption unnecessary. Modbus, DNP3, and ICCP - the protocols that move operational data between RTUs, PLCs, flow computers, and SCADA servers in most North American distribution pipelines - have no native message authentication. A command sent from a legitimate SCADA server and a command sent by an adversary who has gained access to the communication network are indistinguishable to the receiving field device.

Protocol manipulation attacks exploit this absence of authentication in two ways. In a false data injection attack, the adversary sends spoofed sensor readings to the SCADA server, causing operators to see process conditions that do not reflect reality - potentially leading to incorrect control decisions. In a command injection attack, the adversary sends unauthorized commands to field devices - closing valves, changing compressor setpoints, or suppressing safety alarms - while the SCADA display shows normal operation.

3.2 Real-World Precedent: Industroyer and DNP3

The Industroyer malware family, deployed against Ukrainian electric grid infrastructure in 2016 and updated as Industroyer2 in 2022, included dedicated protocol attack modules for IEC 104, IEC 61850, and IEC 60870-5-101. The DNP3 protocol used in North American oil and gas distribution is structurally similar to these IEC protocols in its lack of native authentication. Industroyer's DNP3 module demonstrated that automated protocol manipulation attacks at scale are within the capability of nation-state threat actors and can be adapted to new target environments.

3.3 Controls That Address This Threat

OT-native network monitoring with protocol-aware inspection: Network monitoring solutions designed for OT environments can baseline normal Modbus and DNP3 traffic patterns - which devices communicate with which other devices, what command types are exchanged, and at what frequency. Deviations from that baseline are detectable as anomalies even when the protocol itself provides no authentication.
Application-layer firewalling at field site perimeters: Firewalls capable of inspecting Modbus and DNP3 at the application layer can enforce whitelist rules that permit only expected command types from expected source addresses - rejecting command injection attempts that arrive from unexpected sources.
Unidirectional gateways for highest-consequence field communications: For critical control links where the consequence of command injection is highest - Safety Instrumented System communications, emergency shutdown interfaces - unidirectional gateways (data diodes) that permit data flow in only one direction eliminate command injection as an attack vector for those specific links.
Network segmentation isolating field communication networks: Keeping field communication networks - the networks carrying Modbus and DNP3 traffic between SCADA servers and RTUs - isolated from corporate IT and from internet-accessible segments prevents adversaries from reaching the protocol layer without first compromising the OT network through another vector.

Technical Note

IEC 62443 Security Level 2 requirements include authentication of all network connections - but legacy Modbus and DNP3 devices cannot meet this requirement at the device level. The IEC 62443 response to this is compensating controls at the conduit: the network pathway carrying legacy protocol traffic is secured through firewalling and monitoring, rather than requiring device-level authentication that the legacy device cannot support. This is the correct architectural approach for the installed base of field devices in North American distribution pipelines.

Threat 4: Supply Chain Compromise via SCADA Software Updates

4.1 How This Attack Works in a Distribution Environment

SCADA platforms used in oil and gas distribution are commercial software products developed and maintained by a small number of major vendors. The concentration of this vendor landscape - a significant portion of North American pipeline SCADA environments run on platforms from a handful of suppliers - means that a successful software supply chain compromise against one of those vendors creates simultaneous exposure across a large number of operator environments.

The attack mechanism is the same as in any software supply chain compromise: the adversary infiltrates the vendor's build or distribution infrastructure and embeds malicious code in a software update that is digitally signed and distributed through the vendor's legitimate update channel. When operators apply the update through their normal patch management process, they are installing a compromised package that passes signature verification. The malicious payload is then active within the SCADA environment with the privileges of the SCADA platform itself.

4.2 Why SCADA Platform Updates Are High-Risk in Distribution Operations

Distribution SCADA operators face a specific tension with software updates that makes supply chain attacks particularly effective: patch management is both a security requirement and an operational risk. Applying an untested SCADA platform update to a live pipeline control system carries the risk of introducing a regression that affects SCADA functionality - which is why many operators defer updates or apply them only during scheduled maintenance outages. This means that when a compromised update is distributed, it may persist in the environment for an extended period before being identified.

4.3 Controls That Address This Threat

Isolated SCADA staging environment for update testing: All SCADA platform updates are applied to a non-production staging environment first, where behavioral monitoring can observe the update before it is deployed to production systems. Any unexpected network connections, new processes, or anomalous file activity in the staging environment is investigated before production deployment.
File integrity monitoring on SCADA servers and engineering workstations: Baseline file system state is documented and monitored for unexpected changes. Post-update file integrity comparison identifies files modified beyond the documented scope of the update.
CIP-013 and IEC 62443-2-4 supply chain requirements in vendor contracts: Require SCADA platform vendors to notify you of security incidents affecting their development and distribution infrastructure. Require software bill of materials (SBOM) documentation for SCADA platform releases. For operators subject to NERC CIP, CIP-013 mandates these supply chain security practices.
Network egress monitoring from SCADA servers: Compromised SCADA software typically attempts to establish command and control communications with attacker infrastructure. Monitoring outbound connections from SCADA servers against a documented baseline of expected external communications - vendor licensing servers, NTP servers, update repositories - detects unexpected egress that indicates a compromise.

Threat 5: Nation-State Pre-Positioning for Infrastructure Disruption

5.1 How This Threat Operates in Distribution Infrastructure

Nation-state threat actors targeting oil and gas distribution infrastructure do not operate like ransomware groups. They are not seeking immediate financial return. Their objective is to achieve persistent, undetected access to SCADA environments - positioning themselves to cause physical disruption at a time and scale of their choosing, in coordination with broader geopolitical objectives.

The threat group VOLTZITE, tracked by Dragos with technical overlap with the Chinese state-sponsored group Volt Typhoon, has been documented conducting sustained reconnaissance against US energy infrastructure including pipeline operations. The group's tradecraft is specifically designed to avoid detection: they use living-off-the-land techniques that blend with normal administrative activity, avoid deploying malware that signature-based tools would detect, and prioritize understanding operational systems and process dependencies over immediate disruption.

5.2 What Pre-Positioning Looks Like in a SCADA Environment

Pre-positioned nation-state adversaries in a SCADA environment typically leave minimal artifacts. They access legitimate administrative accounts rather than deploying malware. They map network topology, enumerate SCADA configuration files and process descriptions, and identify the assets and communication pathways that would need to be disrupted to cause maximum operational impact. The access pattern looks like routine administrative activity to any tool that does not establish a behavioral baseline for what normal administrative activity looks like in that specific environment.

Detection requires OT-native behavioral analytics - not signature-based tools. An OT monitoring platform that has established baselines for which accounts access which systems, at what times, and from which source addresses can identify the subtle deviations that characterize pre-positioning activity: administrative access at unusual hours, enumeration of SCADA configuration files, reconnaissance of network segmentation boundaries.

5.3 Controls That Address This Threat

OT-native network monitoring with behavioral baselining: This is the primary detection control for nation-state pre-positioning. Signature-based tools do not detect living-off-the-land techniques. Behavioral analytics that establish baselines for normal OT network activity and flag deviations are the tool class that catches this threat.
Privileged access management for SCADA administrative accounts: Pre-positioned adversaries use legitimate administrative credentials to maintain access. Privileged access management that enforces just-in-time provisioning, session recording, and anomaly detection for administrative sessions limits the utility of compromised credentials and creates forensic evidence of unauthorized use.
Threat intelligence specific to oil and gas OT targeting: CISA, E-ISAC, and sector-specific ISACs publish threat intelligence on nation-state activity targeting oil and gas infrastructure. This intelligence includes indicators of compromise and behavioral patterns associated with known threat groups. Integrating this intelligence into OT monitoring platforms improves detection of threat-group-specific techniques.
Incident response planning that includes nation-state scenarios: Response to a pre-positioned nation-state adversary is qualitatively different from response to a ransomware incident. The decision to eject an adversary must be made deliberately - an uncoordinated response may trigger an adversary to execute a destructive payload before being fully removed. Tabletop exercises that include nation-state pre-positioning scenarios, and coordination protocols with CISA and FBI, should be part of every distribution operator's incident response planning.

Bottom Line

The five SCADA threats in this post are not theoretical future risks. They are active, documented threat vectors that have been used against oil and gas distribution infrastructure in North America within the past three years. The controls that address them are implementable within the operational constraints of continuous production environments. The operators who have addressed these threats are not the ones who spent the most on security technology. They are the ones who understood the specific threat environment for their sector and built their security program around it.

6. Detection and Response: What to Do When SCADA Indicators Appear

6.1 Indicators of Compromise Specific to SCADA Environments

The following behavioral indicators should be investigated immediately when observed in a distribution SCADA environment. None of these are definitive proof of compromise, but each represents an anomaly that warrants immediate investigation before it is attributed to normal operations.

Indicator	Possible Explanation	Immediate Action
New inbound connection to SCADA server from unknown source IP	Unauthorized remote access attempt; compromised credential use; misconfigured firewall rule	Block source IP at firewall; review authentication logs; verify no unauthorized sessions are active
RTU or PLC configuration file accessed outside of scheduled maintenance window	Unauthorized configuration review consistent with pre-positioning; insider threat; compromised engineering workstation	Verify with operations who accessed the file; review access logs; inspect for unauthorized configuration changes
SCADA server initiating outbound connection to unfamiliar external IP	Ransomware command and control; supply chain compromise beacon; legitimate vendor connection not in baseline	Block outbound connection; investigate process initiating the connection; compare against known-good software baseline
Unusual Modbus or DNP3 command types observed in OT network traffic	Protocol manipulation attempt; misconfigured device; adversary testing command injection capability	Capture traffic for analysis; verify field device state matches expected SCADA display; review firewall logs for source of anomalous commands
Authentication failures on SCADA or historian server accounts outside business hours	Credential stuffing; brute force; compromised credential being used from unexpected location	Lock affected accounts; require credential reset; review for successful authentication from same source

6.2 The First 30 Minutes of a SCADA Security Incident

When a SCADA security indicator is confirmed as a potential incident, the first 30 minutes determine whether the incident is contained or escalates to operational impact. The following sequence applies to most confirmed SCADA security events in distribution operations:

Notify the operations supervisor and shift lead immediately: Security incidents in SCADA environments are operations events, not just IT events. Operations leadership must be in the decision loop from the first confirmed indicator.
Do not immediately shut down SCADA or disconnect field devices: Disconnecting SCADA from field devices removes operator visibility and may create more operational risk than the incident itself. Maintain SCADA connectivity while assessing the scope and nature of the incident.
Isolate the IT/OT boundary: If the incident appears to have originated from the IT network, isolating the IT/OT boundary - blocking traffic between the Industrial DMZ and the corporate IT network - contains the incident to the OT environment while maintaining operational SCADA functionality.
Preserve forensic evidence before taking remediation actions: Memory captures, network traffic logs, and authentication logs from SCADA servers are the primary forensic evidence sources. These should be preserved before any system modifications or restarts that might overwrite evidence.
Notify CISA and TSA per regulatory reporting requirements: Pipeline operators subject to TSA Security Directives are required to report confirmed cybersecurity incidents to CISA within 24 hours. NERC CIP operators have similar reporting obligations to E-ISAC and CISA. Early notification enables federal support and threat intelligence sharing.

Frequently Asked Questions

Are SCADA systems in oil and gas distribution accessible from the internet?

More often than asset owners realize. Shodan and similar scanning tools continuously index internet-accessible industrial control system interfaces. SCADA components found on the public internet in oil and gas distribution environments include flow computer web interfaces, remote terminal unit management ports, historian server web services, and in some cases SCADA HMI remote access portals that were configured for operator convenience without adequate access controls. An external attack surface assessment of your distribution SCADA environment - scanning for internet-accessible ICS components from outside your network - is the only way to confirm your actual exposure. Operators frequently discover internet-facing OT assets through this exercise that are not documented in their network architecture.

How do ransomware operators decide which oil and gas operators to target?

Ransomware operators targeting industrial organizations conduct reconnaissance before selecting targets. The primary selection criteria are likelihood of payment and ability to pay. Pipeline distribution operators score highly on both metrics: operational continuity obligations create pressure to pay quickly, and the financial scale of pipeline operations indicates ability to pay large ransoms. Secondary selection criteria include the availability of initial access - operators with known internet-exposed assets or recently leaked VPN credentials are easier targets than those with enforced network perimeters. Ransomware operators who specifically target OT environments, such as the groups tracked by Dragos as targeting industrial organizations, also factor in the operational impact of SCADA disruption - higher impact means higher ransom leverage.

What is the difference between a SCADA availability attack and a SCADA manipulation attack?

A SCADA availability attack - typically ransomware or a denial-of-service attack - removes the operator's ability to see and control field assets. Production may continue normally in the field, but the operator is flying blind and typically elects to halt operations rather than continue without monitoring. A SCADA manipulation attack is more dangerous: the SCADA display continues to show normal operations while the adversary has changed process conditions in the field. Operators make control decisions based on false data, potentially without realizing the system has been compromised. The Triton/TRISIS attack on a petrochemical Safety Instrumented System was a manipulation attack - the adversary was not trying to shut down the SIS but to disable it so that a subsequent process attack would not trigger an emergency shutdown. Manipulation attacks are harder to detect than availability attacks and have higher potential for physical consequences.

How does the TSA Pipeline Security Directive address these five threats?

TSA Security Directives issued since 2021 address three of the five threats directly. The MFA and network segmentation requirements address remote access exploitation (Threat 2) and provide partial protection against ransomware lateral movement (Threat 1). The OT security monitoring requirement creates detection capability relevant to protocol manipulation (Threat 3) and nation-state pre-positioning (Threat 5). Supply chain security (Threat 4) is not explicitly mandated by current TSA Directives at the level required to address software supply chain compromise - this is an area where IEC 62443 supply chain requirements and voluntary adoption of CISA supply chain security guidance provide coverage beyond the TSA mandate.