Inside a Refinery Hack: How One ICS Vulnerability Almost Led to Catastrophe

Red Team Assessment Uncovers Critical ICS Vulnerabilities at a Balkan Oil Refinery

Oil & Gas companies face a growing cyber threat landscape, as attacks on industrial control systems (ICS) become more sophisticated. Unlike IT breaches, ICS attacks can cause physical destruction – from equipment damage to endangering human life. In regions with relatively lower cybersecurity investment, such as parts of the Balkan peninsula, legacy systems and lax security practices leave critical infrastructure especially vulnerable.

Real-world incidents have demonstrated the stakes: the Triton/Trisis malware in 2017 targeted safety controllers in a petrochemical plant, attempting to disable safety systems and potentially cause catastrophic damage. Similarly, a cyberattack on Ukraine's power grid in 2015 allowed attackers to remotely open circuit breakers via the SCADA system, resulting in a blackout affecting approximately 225,000 customers.

These cases underscore that determined adversaries can penetrate industrial networks and manipulate physical processes. Many ICS environments – especially in regions still developing their cyber defenses – have not kept pace with such threats. This case study illustrates how multiple weaknesses in an ICS network could be chained together by an attacker – and how close the facility came to a potential disaster.

The Attack Kill Chain

Initial Foothold – Compromising a PLC:

Our Red Team began with reconnaissance and discovered an exploitable Programmable Logic Controller (PLC) on the refinery's process network. This controller, an RTU overseeing a critical part of the refining process, was accessible due to a misconfigured remote access rule. The device was running outdated firmware with a known vulnerability and still used the vendor's default credentials.

By exploiting the PLC's firmware vulnerability, our team gained access to the controller. This initial compromise became our beachhead into the ICS environment (Purdue Model Level 1). The PLC's communications used an ICS protocol with no encryption or authentication, allowing us to intercept traffic and issue commands on the local control network.

Pivoting Through the ICS Network:

The refinery's network was poorly segmented – the Level 1 controller network was directly routable to the Level 2 HMI (Human-Machine Interface) network. Using our foothold on the PLC, we sniffed network traffic and harvested credentials of an engineer who had recently logged into an HMI station (the credentials were transmitted in plaintext).

With these HMI login credentials, we accessed the operator station at Level 2, which provided us a view of plant operations and the ability to issue control commands. The HMI itself was an outdated Windows workstation without modern endpoint protection; it had an unpatched SMB service, which we exploited to establish persistence.

From the HMI on Level 2, we escalated further. The refinery had a Level 3 operations network hosting engineering workstations, historians, and a local domain controller for ICS operations. The HMI was connected to this Level 3 network, acting as a pivot point (a dangerous practice where an HMI is dual-homed on both Level 2 and Level 3).

Using the HMI foothold, we harvested Active Directory credentials cached on that machine. These credentials belonged to an engineer with domain admin privileges for the ICS domain – indicating overly permissive access policies. We then remotely accessed the engineering workstation (Level 3) using these stolen admin credentials.

On the engineering station, we found unprotected project files and control logic backups containing hardcoded passwords for other PLCs and the Safety Instrumented System (SIS) controllers. The same password was reused across multiple devices. Using these passwords, we gained access to safety PLCs responsible for emergency shutdowns (Level 1, SIS controllers).

Additionally, we examined connections to the corporate IT network (Level 4). The refinery's OT-IT separation was weak: the historian server in Level 3 had a second network interface connected to the corporate network for reporting purposes. This interface was not properly firewalled. Through the historian, we extended our reach into the IT network, finding an Active Directory trust between the corporate domain and the ICS domain.

Throughout our lateral movement, we employed "living off the land" tactics (leveraging built-in Windows tools) to avoid triggering antivirus. We tunneled our communications in protocols allowed by the few firewall rules that existed – for instance, using the HTTP port of the historian to send command-and-control traffic. Every Defense in Depth measure that should have stopped us had gaps or was nonexistent.

Attack Path Mapped to Purdue Model: Our red team exercise illustrated how an attacker could start from a Level 1 device and progressively move up and across the ICS environment to reach critical Level 3 systems, even breaching into Level 4. By the end of our assessment, we had demonstrated full compromise of the refinery's ICS: we controlled critical process PLCs, operator HMIs, the engineering workstation, the historian, and the safety system controllers.

Throughout the engagement, the refinery's detection capabilities failed to detect our presence – the ICS network had no intrusion detection sensors, and the IT security team was not monitoring OT logs. This is typical of many industrial organizations where OT security is still maturing.

The Potential Catastrophe

With the access we obtained, an attacker could manipulate the refinery's processes in ways that threaten safety, disrupt operations, cause financial losses, and harm the environment.

The SIS controllers are the last line of defense designed to safely shut down processes if unsafe conditions are detected. We proved we could reprogram these safety PLCs. A malicious actor could upload logic to disable safety interlocks or alter sensor readings – making the SIS think everything is normal even as a reactor overheats or pressure builds to critical levels. This scenario is similar to the Triton malware attack, where adversaries manipulated safety controller logic.

Even without touching the SIS, an attacker with control of process PLCs and HMIs could wreak havoc by issuing unauthorized commands to open or close valves, over-speed pumps, or disable cooling systems. If a crucial cooling valve in the distillation unit is forced shut while heat input continues, pressure would spike rapidly. If alarms were silenced and SIS is compromised, the result could be a ruptured column or an explosion.

This is not hypothetical: in 2014, a cyberattack on a German steel mill caused a furnace to overheat by disrupting control systems, leading to "massive" physical damage. In a refinery, such an incident could ignite flammable hydrocarbons, potentially causing a fire or explosion.

The safety risks to personnel are extreme, with potential for injuries or fatalities. Operational disruptions would be severe: a major equipment failure could force the refinery offline for weeks. With thousands of barrels processed daily, the financial impact could reach millions in lost revenue.

Beyond direct losses, there would be costly repairs – replacing damaged industrial equipment can cost tens of millions of dollars. Environmental damage could include toxic gas releases, air quality impacts, or oil spills if storage tanks or pipelines were compromised.

Importantly, a targeted cyberattack could coordinate multiple failures to amplify chaos – shutting down fire suppression systems or injecting false data into operator displays to mask the attack or misdirect response efforts.

How We Secured the Refinery

The refinery implemented a comprehensive remediation plan guided by the ISA/IEC 62443 standards, addressing vulnerabilities across technology, network architecture, and organizational practices.

Immediate Fixes – Patching and Hardening: All vulnerable PLCs and field devices were patched or taken offline until updates could be applied. Default passwords on PLCs, RTUs, and network equipment were changed to strong, unique credentials. The hardcoded passwords in project files were removed, with engineers trained to use secure vaults for credentials instead. Compromised HMIs and engineering workstations were rebuilt with updated operating systems and current patches. Unauthorized remote-access tools were replaced with secure solutions integrated with the refinery's authentication system.

Network Segmentation and Access Controls: The network architecture was redesigned according to the Purdue Model and ISA 62443's concept of zones and conduits. Clear network zones were established: enterprise IT (Level 4/5), an isolated industrial DMZ (Level 3.5) for IT/OT data sharing, the control network (Level 3), and separate zones for safety systems and field devices (Levels 1-2).

Firewalls and data diodes (one-way gateways) were installed to strictly limit communications between zones. The historian server was moved into a DMZ zone; it now polls data from the control network but only pushes data one-way to a database that the enterprise network can query. The rule that had allowed remote access to the vulnerable PLC was removed; now, any remote access to Level 1/2 devices must go through a secured jump host with multi-factor authentication.

Network intrusion detection sensors tuned for ICS protocols were implemented at key points to monitor for suspicious patterns. After segmentation, an attacker can no longer traverse freely across levels – even if a Level 1 device is compromised, additional security controls at each conduit make further movement exponentially harder.

Secure Configuration and Monitoring: The refinery adopted strict configuration baselines for all OT systems: disabling unused services, whitelisting approved applications, enabling security logging, and implementing properly tuned antivirus or application control software. The engineering workstations and HMIs were configured to run with least privilege. All remote connections to the ICS now go through a secure gateway that logs activity and requires approval.

An ICS-focused Security Information and Event Management (SIEM) solution was deployed to aggregate and analyze logs from controllers, ICS servers, and networking equipment. This addresses the previous lack of visibility – the security team now receives alerts if a new device appears on the control network or if a PLC enters programming mode at unusual hours.

Governance and Culture Change: The company established a cross-disciplinary ICS cybersecurity task force, bringing together engineers, IT security staff, and plant managers. Executives championed the importance of cybersecurity in operations, making it clear that production targets must balance with security and safety.

The refinery's security program was aligned with both ISA/IEC 62443 and relevant parts of NERC CIP (Critical Infrastructure Protection standards). They now maintain an up-to-date inventory of all ICS assets, enforce role-based access controls, and have established incident response and recovery plans.

A formal change management process was implemented for the ICS. Now, any change to a critical system must undergo security review and testing in a simulation environment if possible. The refinery also established ongoing penetration testing to periodically test their defenses. In a re-test, our team attempted the same attack path and was blocked at multiple points, with the security operations center detecting our activities in real-time.