Leveraging Default Credentials in Industrial Control Systems

The password was in the installation manual. Nobody had changed it in eleven years.

There is a world beneath the corporate network — a world of programmable logic controllers, human-machine interfaces, variable frequency drives, and SCADA servers. It controls physical processes: the flow of water, the temperature of furnaces, the speed of conveyor belts, the pressure in pipelines, the position of robotic arms. It is called operational technology — OT — and it operates under a set of constraints that are fundamentally different from anything encountered in traditional IT.

In IT, a security vulnerability is patched within days. In OT, a security vulnerability may persist for the lifetime of the equipment — because the equipment cannot be taken offline for patching, because the manufacturer no longer supports the firmware, because the system integrator who programmed it went out of business in 2016, or because nobody is certain what will happen if the configuration is changed.

On this engagement, we found programmable logic controllers running with the manufacturer's default credentials — the same username and password printed in the installation manual, unchanged since the day the equipment was commissioned. We could read process variables. We could modify setpoints. We could upload new logic to the controllers. We could stop a production line.

We did none of these things. But we demonstrated, in controlled and carefully scoped conditions, that an attacker who reached the OT network could.

Why This Engagement Was Different

Before describing the technical findings, we must explain how OT penetration testing differs from IT penetration testing. The distinction is not academic — it has direct consequences for safety, methodology, and reporting.

OT penetration testing requires a different mindset, a different methodology, and different rules of engagement. The scope is narrower. The pace is slower. An OT engineer from the client's team is present at all times during testing of live process networks. Every action is discussed, agreed, and documented before it is performed. The tester must understand not only the cybersecurity implications of each action but the process safety implications.

This engagement was conducted during a planned maintenance shutdown — a two-week window during which production was halted and the process equipment was in a safe, de-energised state. This allowed us to test the OT network with significantly reduced safety risk, whilst still assessing the systems in their operational configuration.

The Engagement Brief

The client was a food and beverage manufacturer operating a large production facility. The facility ran three production lines — mixing, filling, and packaging — controlled by a SCADA system that managed approximately fifty PLCs, twelve HMI panels, four engineering workstations, and a centralised SCADA server. The OT infrastructure had been installed in phases over fifteen years, with the oldest equipment dating from 2010 and the newest from 2022.

The client had recently engaged a consultancy to conduct an OT asset inventory and risk assessment, which had identified the lack of a historical OT security assessment as a significant gap. They engaged us to conduct the first penetration test of their OT environment. The scope covered the OT network, the IT/OT boundary, and the systems that bridged both environments.

We were given a starting position on the corporate IT network — simulating an attacker who had compromised the IT environment (through any of the methods described in our previous articles) and was attempting to pivot into the OT network. A secondary assessment position was provided directly on the OT network to assess the security posture of the OT environment in isolation.

The IT/OT Boundary

The first question on any OT engagement is: can an attacker on the IT network reach the OT network? The answer determines whether the OT environment's security posture is relevant to IT-originating threats, or whether it is protected by network isolation alone.

The client's network architecture included a demilitarised zone (DMZ) between the IT and OT networks — a standard architectural pattern recommended by IEC 62443 and the Purdue Model for industrial network segmentation. The DMZ contained a historian server that collected process data from the OT network and made it available to business intelligence systems on the IT network.

The architecture followed the Purdue Model — IT and OT were separated by a DMZ with firewalls on both sides. On paper, this was a correct implementation. We tested the firewall rules from the IT network.

The IT-side firewall correctly blocked direct access from the corporate network to the OT operations and process networks. The DMZ was the only permissible transit point. However, the DMZ itself had vulnerabilities.

The remote access gateway at 172.16.100.30 was an appliance that allowed vendor engineers to connect remotely for maintenance. It was accessible from the IT network on port 443. The appliance was running firmware from 2021 and was vulnerable to CVE-2023-46805 — an authentication bypass vulnerability that had been widely exploited in the wild. However, as this was an OT engagement with strict rules about modifying systems, we documented the vulnerability without exploitation and focused our assessment on the direct OT network position.

The OT Network — A Different Era

From our direct assessment position on the OT operations network at 10.100.0.0/24, we performed careful, rate-limited enumeration of the process network at 10.100.1.0/24. Scanning in OT environments is performed at a fraction of the speed used in IT — some older PLCs will fault or reboot if they receive network traffic faster than they can process it. We scanned at a rate of one packet per second per host, targeting only known industrial protocol ports.

The process network contained fifty-five addressable devices: thirty-one PLCs from two manufacturers, twelve HMI panels, eight variable frequency drives, and four safety-rated PLCs. The equipment spanned three generations of technology — the oldest S7-300 controllers dated from 2010, the newest S7-1500 units from 2022.

Every PLC had an HTTP web server enabled. Every HMI had an HTTP interface and a VNC service running. The Modbus/TCP devices had no authentication — Modbus is an inherently unauthenticated protocol by design. The network was entirely flat — no segmentation between the PLCs controlling the mixing line and the PLCs controlling the packaging line, no separation between process controllers and safety controllers.

Default Credentials — The Catalogue of Inertia

We tested each device's management interface against the manufacturer's documented default credentials. These credentials are published in installation manuals, available on manufacturer websites, and catalogued in publicly available databases such as the SCADA Default Password List.

The results were systematic.

Of fifty-five devices on the process network, forty-eight retained default credentials or had no authentication capability — an overall default credential rate of eighty-seven per cent.

Some of these results require context. The Siemens S7-300 series, for example, does not support authentication on the S7comm protocol — it was designed in an era before industrial cybersecurity was a consideration. The S7-300 cannot be 'fixed' with a password change because the protocol has no concept of a password. The only mitigation is network-level access control — ensuring that nothing untrusted can communicate with it. The Modbus/TCP devices are similarly limited: Modbus is an unauthenticated protocol by design. These are not configuration failures — they are architectural constraints inherited from a generation of equipment designed for isolated, air-gapped networks.

The newer equipment, however, had no such excuse. The S7-1200 and S7-1500 controllers support access protection — password-based restrictions on who can read, write, or modify the controller's programme. The Allen-Bradley ControlLogix supports CIP Security — certificate-based authentication. These capabilities existed. They had simply not been enabled.

Demonstrating Impact — Read, Write, Control

With the client's OT operations team present and the process equipment in a safe, de-energised state, we demonstrated the actions an attacker could perform with the access available through default credentials.

Reading Process Variables

Full read access to every process variable, every setpoint, every control state. The mixing speed setpoint (450 RPM), the batch duration (180 seconds), the tank levels, the temperature targets — all readable without authentication. During normal operation, this data would reveal the exact parameters of the production process — information that constitutes trade secrets and proprietary manufacturing knowledge.

Writing Setpoints

With explicit written approval from the client's OT operations team, and with the process equipment de-energised and in a safe state, we demonstrated that the S7comm connection also permitted write access to the PLC's data blocks.

We wrote a benign test value to a designated test register — not a live process variable — and confirmed that the value was accepted. The PLC did not distinguish between a legitimate write from the SCADA server and our write from an assessment laptop. No authentication was required. No audit trail was generated on the PLC.

In an operational scenario, the ability to write to process variables means the ability to change setpoints — the target values that the control system tries to maintain. Changing a temperature setpoint, a pressure limit, a mixing speed, or a fill volume would cause the physical process to behave differently. Depending on the process, this could result in spoiled product, equipment damage, environmental release, or — in safety-critical processes — physical harm.

Programme Upload and Download

The most severe capability we demonstrated was the ability to upload and download PLC programmes. The S7-300 and the unprotected S7-1200 controllers permitted full programme access — we could download the running logic from the PLC (effectively stealing the programme), modify it, and upload a replacement. The PLC had no mechanism to verify the integrity or provenance of the programme being uploaded.

We downloaded the programme from one S7-1200 controller with the client's approval, decompiled it, and demonstrated the ability to modify the logic offline. We did not upload any modified programme. The purpose of the demonstration was to confirm the capability — the consequence of arbitrary logic modification in an industrial controller does not require demonstration.

The HMI Panels

The twelve HMI (Human-Machine Interface) panels provided the operator view of the production process — graphical displays showing tank levels, temperatures, motor states, alarm conditions, and control buttons for starting and stopping process sequences. They were the primary interface between the human operator and the physical process.

Ten of twelve HMI panels had their administrative web interface accessible with default credentials. Eight of twelve had VNC services running with no password — providing full remote graphical access to the HMI display. Through VNC, we could see exactly what the operator standing in front of the panel would see — and interact with the same controls.

Through unauthenticated VNC to the HMI panels, an attacker could start and stop production batches, modify recipe parameters, override automated controls, and dismiss safety alarms. The HMI is the control surface that operators use to manage the physical process. Unauthenticated remote access to the HMI is, functionally, unauthenticated control of the production line.

The Engineering Workstations

The four engineering workstations at 10.100.0.20–23 were Windows 10 machines running the PLC programming software (TIA Portal and Studio 5000). These workstations were used by the control engineers to develop, modify, and upload PLC programmes. They were the keys to the entire control system.

The workstations were domain-joined to the corporate Active Directory — the same domain as the IT environment. The SCADA server at 10.100.0.10 was also domain-joined. This meant that domain credentials valid in the IT environment were also valid on the OT engineering workstations. If the corporate domain was compromised through any IT-side attack, those credentials would grant access to the systems that programme and configure every PLC in the facility.

Two of the four engineering workstations had RDP enabled and accessible from the OT operations network. One had an active session — a control engineer had left their session connected and the workstation had not been locked. Through that session, we had access to TIA Portal with an open project file containing the programme logic for the entire mixing line.

The engineering workstations did not have EDR installed. They did not have application whitelisting. They were running Windows 10 version 21H2, which had reached end of support. They were patched through the DMZ patch server, but the patch cycle was quarterly — three months of security updates behind the IT environment's seventy-two-hour patching policy.

From IT Network to Process Control

Configuration Inertia and the OT Security Challenge

The findings on this engagement are not unusual. They are representative of the state of OT security across the majority of industrial environments we assess. The reasons are structural, not negligent.

Technique Mapping

Recommendations and Hardening

The remediation timeline for OT is longer than IT by necessity. Changes to PLC configurations must be planned for maintenance windows, validated by control engineers, and tested before the process is restarted. The remediation roadmap reflects this constraint — immediate actions focus on items that can be implemented without process impact (VNC passwords, HTTP admin passwords, workstation lockdown), whilst longer-term actions that require process validation are aligned with the maintenance schedule.

Network segmentation within the OT environment is the single most impactful control for legacy devices that cannot support authentication. If the S7-300 controllers cannot be protected with passwords, they can be protected with network-level access control — ensuring that only the SCADA server and the designated engineering workstation can communicate with them. This does not fix the device, but it reduces the attack surface to a manageable number of authorised communication paths.

Separating the OT Active Directory domain from the corporate IT domain breaks the credential chain that allows an IT-side compromise to yield access to OT engineering workstations. A dedicated OT domain — or, for smaller environments, local accounts with unique passwords managed by a privileged access management solution — ensures that IT credentials are not valid in the OT environment.

OT-specific network monitoring using passive anomaly detection is the primary detection control for environments where endpoint security agents cannot be deployed. These systems learn the normal communication patterns on the OT network — which PLCs talk to which HMIs, on which protocols, at which intervals — and alert on deviations. An attacker connecting to a PLC from an unfamiliar IP address, or reading data blocks that are normally accessed only by the SCADA server, would generate an anomaly alert.

The password was in the manual. The manual was on the internet.

There is a tension in OT security that does not exist in IT. In IT, a default credential is a straightforward finding with a straightforward remediation — change the password. In OT, a default credential may have persisted for eleven years because changing it requires a maintenance shutdown, a control engineer, a system integrator, a vendor validation, and a risk assessment that weighs the cybersecurity benefit against the operational risk of modifying a running control system.

This tension is real. It is not an excuse for inaction, but it is an explanation for the pace of change. The organisations that are making progress in OT security are the ones that have accepted two truths simultaneously: that their OT environment contains risks that must be addressed, and that addressing them requires a different approach — slower, more cautious, more collaborative — than IT security allows.

The PLCs on this engagement had been running with default credentials for over a decade. Not because nobody cared, but because nobody had been asked to look. The first OT penetration test is always the hardest — not because the findings are surprising, but because they make visible risks that were previously invisible.

Until next time — stay sharp, stay curious, and check the default passwords on the equipment that runs your physical world. They are printed in a manual. The manual is on the internet.