Compromising Industrial Processes using Web-Based Programmable Logic Controller Malware

Compromising Industrial Processes using Web-Based Programmable Logic Controller Malware

Speakers: Ryan Pickren

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=3lOh9LCd3M

Overview

This article delves into a groundbreaking security talk presented by Ryan Pickren, which introduces a novel and highly effective method for developing Programmable Logic Controller (PLC) malware. Termed Web-Based PLC Malware (WB PLC malware), this new approach fundamentally shifts the attack surface for industrial control systems (ICS) by exclusively targeting the web applications hosted on embedded webservers within modern PLCs. Unlike traditional PLC malware, which focuses on control logic or firmware, WB PLC malware leverages legitimate web application program interfaces (APIs) exposed by these admin portals to stealthily manipulate real-world machinery.

The research highlights a critical, emerging threat driven by the widespread adoption of embedded webservers in contemporary PLCs. These are not standard IT web vulnerabilities but rather concerns specific to the hierarchical network architecture of ICS, often referred to as the Purdue Enterprise Reference Architecture (PERA). Pickren demonstrates that this web-centric attack vector offers significant advantages, including platform independence, ease of deployment, and superior persistence. The potential impact is severe, ranging from falsifying sensor readings and disabling safety alarms to manipulating physical actuators, which could lead to catastrophic incidents or even loss of life, depending on the industrial process.

To validate these claims, the talk presents IronSpider, a prototype implementation of WB PLC malware that executed a Stuxnet-style attack. This proof-of-concept exploited zero-day vulnerabilities (CVE-2022-45137, CVE-2022-45138, CVE-2022-45139, and CVE-2022-45140) discovered in a widely-used PLC model, the WAGO 750. Crucially, the research reveals that over 80% of the global market share of PLCs from every major vendor are susceptible to this proposed attack vector, underscoring the pervasive nature of this vulnerability. The talk concludes by discussing essential countermeasures and mitigations, emphasizing the urgent need for a re-evaluation of current ICS security paradigms.

Background

▶ Watch: Introducing novel Web-Based PLC Malware and its advantages (0:20)

Industrial Control Systems (ICS) form the backbone of critical infrastructure, seamlessly integrating information technology (IT) capabilities with the precise control of physical systems. At the core of these systems are Programmable Logic Controllers (PLCs), which act as the digital brains, monitoring sensor inputs, executing complex calculations based on predefined control logic, and issuing commands to physical actuators. Process engineers typically program PLCs using IEC 61131-3 compliant languages, such as ladder diagram, which are then compiled into binary executables. Below this control logic lies a firmware layer responsible for low-level hardware interaction.

A pivotal evolution in recent years has been the integration of customizable embedded webservers within this firmware layer. These webservers provide a convenient, browser-based interface for accessing administrative configurations, monitoring operational parameters, and even directly controlling physical processes. This trend has profoundly transformed the ICS ecosystem, introducing new attack surfaces that differ significantly from those found in traditional IT or consumer IoT environments. As summarized in Table I (referenced in the talk), IoT device webservers are typically used for initial, one-time setup, feature manufacturer-authored front-end code, are accessed by personal devices, and are vulnerable to standard web attacks. In contrast, PLC embedded webservers are designed for continuous monitoring and control, host front-end code authored by both the customer and device manufacturer, are often accessed by dedicated hardware like microbrowsers, and are uniquely susceptible to persistent and covert code execution. This distinction is fundamental to understanding the novel attack surface identified by Pickren's research.

Prior work, such as that by Sasaki et al., demonstrated that edge device ICS webservers, like Remote Management Devices, often face the Internet and lack basic security. Pickren's research builds upon this by revealing how PLC webservers, despite operating deep within private ICS networks and hosting programmable front-ends, present surprisingly ideal environments for web-based malware.

Traditional PLC malware, which includes malicious control logic programs (e.g., Stuxnet, LLB, LogicLocker) and malicious firmware images (e.g., HARVEY, Durin), operates directly on the PLC device itself, typically within Level 1 of the PERA model. Infection usually occurs via network access (e.g., a compromised Engineering Workstation (EWS)) or physical access (e.g., an exposed JTAG port), often requiring additional Windows malware or human assets. These traditional methods impose strict hardware requirements, real-time operating system constraints, and limited network connectivity. Firmware malware demands tedious model-specific reverse engineering, while control logic malware executes within a user-code sandbox with restricted API access. Crucially, traditional PLC malware is confined to segregated industrial networks, typically lacking public internet connectivity.

In stark contrast, Web-Based PLC malware (Figure 1.C, referenced in the talk) compromises the web application hosted by the PLC's embedded webserver using malicious JavaScript code. This code then executes client-side on various browser-equipped devices throughout the ICS environment, such as EWSs or Human-Machine Interfaces (HMIs), rather than on the PLC itself. The malware leverages ambient browser-based credentials to interact with the PLC's legitimate web APIs. This strategy offers significant advantages: it is easier to deploy, capable of online operations, largely platform-independent, and achieves high persistence. A new infection scenario, termed Web Access, is introduced, where an attacker lures a dual-homed ICS operator to view a malicious website from the public internet. This can leverage vulnerabilities like Cross-Origin Resource Sharing (CORS) misconfigurations to pivot into the private industrial network and transfer a malicious User-defined Web Page (UWP) to the PLC's web server. This highlights how PLC web vulnerabilities are more remotely exploitable than previous security issues, though traditional network and physical access methods also remain viable for WB PLC malware. The key difference in execution is that while WB malware resides in PLC memory, it executes in web browsers on PERA Levels 2 and 3. These Level 3 browsers often have public internet access, enabling web-based Command & Control (C2) communication that can traverse the business network and escape to the public internet.

Key Findings

▶ Watch: Rise of embedded webservers in modern PLCs as new attack surface (2:05)

The core contribution of this research is the introduction and validation of Web-Based PLC malware as a novel and highly potent threat to industrial control systems. The key findings demonstrate a significant paradigm shift in how PLCs can be compromised:

1. Novel Attack Vector: The research establishes that infecting the web application layer of modern PLC embedded webservers provides a new, flexible, and resilient method for attacking ICS environments. This approach circumvents the inherent limitations of traditional control logic and firmware-based malware.
2. Superior Capabilities: WB PLC malware, by executing client-side on connected browsers (EWSs, HMIs) and leveraging legitimate web APIs, offers advantages over traditional methods, including platform independence, ease of deployment, and significantly higher persistence. It can perform a range of malicious activities, from falsifying sensor data and disabling safety systems to covertly manipulating actuators.
3. ICS-Specific Web Security Concerns: The talk identifies new web-oriented security challenges unique to ICS environments, distinct from those found in IT or consumer IoT. These relate to the specific architecture of ICS networks, the nature of PLC webservers, and the interplay between web technologies and industrial protocols.
4. Practical Validation with Zero-Days: The effectiveness of WB PLC malware was verified through a Stuxnet-style attack using a prototype called IronSpider. This attack exploited four zero-day vulnerabilities (CVE-2022-45137, CVE-2022-45138, CVE-2022-45139, CVE-2022-45140) discovered in a widely-used PLC model, the WAGO 750, demonstrating real-world exploitability. These vulnerabilities have since been disclosed and fixed.
5. Widespread Generalizability: The research further revealed that this attack vector is not isolated to a single vendor or model. Every major PLC vendor, collectively accounting for over 80% of the global market share, produces PLCs susceptible to WB infections, either through legitimate means or zero-day exploitation.
6. Ineffectiveness of Traditional Defenses: Existing PLC intrusion detection systems (e.g., PLCDefender) and network segregation strategies are largely ineffective against WB PLC malware, as it does not modify control logic or firmware and leverages legitimate web channels for C2 and data exfiltration. Browser-level detection is also challenging due to the malware's legitimate execution context.
7. Proposed Countermeasures: The research outlines practical prevention and detection mechanisms, urging the ICS community to adopt web-oriented defenses, including domain-sandboxing for untrusted JavaScript, enhanced browser exfiltration defenses, and PLC-configured Web Application Firewalls (WAFs) that inspect industrial protocols.

Technical Deep Dive

▶ Watch: Distinguishing PLC webservers' unique vulnerabilities from IoT devices (2:40)

The research introduces a comprehensive, vendor-agnostic framework for understanding and analyzing Web-Based PLC Malware (WB PLC malware), outlining its lifecycle across four distinct stages: Initial Infection, Persistence, Malicious Activities, and Cover Tracks. This framework, depicted in Figure 2 (referenced in the talk), elucidates how malicious front-end code can subvert ICS integrity. The prototype implementation, IronSpider, served to illustrate these concepts by performing a Stuxnet-style attack on a WAGO 750 PLC within a real-world ICS testbed designed to precisely control a three-phase 220VAC industrial motor, mimicking processes like uranium enrichment.

The threat model, detailed in Figure 3 (referenced in the talk), assumes a typical PERA model in critical infrastructure. It posits that Engineering Workstations (EWSs) have dual access to both business and industrial networks, both secured by firewalls. EWSs adhere to IT best practices (up-to-date OS/browsers, strong passwords, antivirus). The PLC itself is assumed to use the most secure settings (password-protected services, encrypted protocols, up-to-date firmware). The adversary is targeted and goal-oriented, possessing basic knowledge of the physical process (e.g., motor control) but lacking specific details like plant layout or I/O pin configurations. The attacker knows the PLC model but not its network location. The primary goal is to maliciously control PLC actuators by injecting JavaScript code into a context executing under the PLC's web origin within the private network. Crucially, the adversary does not aim for system-level compromise of any device or rely on browser zero-days; the malicious JavaScript must execute legitimately within browser-based rules like the JS execution sandbox, Same-Origin Policy, and Site-Isolation protections. Success is defined as covertly changing the motor speed set-point above a critical safety threshold, causing physical damage.

Initial Infection

The Initial Infection stage focuses on deploying malicious JavaScript into a context that executes within the same web origin as the PLC's admin portal. Several strategies were identified (Table II, referenced in the talk):

1. Malicious User-defined Web Pages (UWPs): Many PLC vendors (e.g., Siemens, Allen Bradley, Mitsubishi) allow custom HTML code for HMI dashboards. The research found that a misunderstanding of the Same-Origin Policy could allow a malicious UWP, when viewed by an administrator, to gain full administrative control over the PLC. UWPs can be downloaded via proprietary ICS protocols like CIP PCCC or ISO-TSAP, non-ICS methods like FTP or SD card, or a "Restore from Backup" web API. This typically requires a vulnerability, insecure victim settings, or compromised credentials.
2. Hijacked PLC GUI Files: Vendors like WAGO and Schneider use tools like WebVisu to generate web-based GUIs. These transpiled files (HTML, JavaScript, CSS), hosted on the embedded web server, can be modified in transit or overwritten post-download. The researchers verified this by SSH'ing into a WAGO 750 PLC and overwriting files, again requiring vulnerabilities, insecure protocols, or compromised credentials.
3. ICS Cross-Channel Scripting (XCS): An obscure variant of Cross-Site Scripting (XSS) where the payload is transferred via non-web protocols (e.g., SNMP, FTP). This vulnerability type is common in ICS due to real-time constraints. The team discovered multiple zero-day XCS vulnerabilities, including an unauthenticated SNMP XCS vulnerability (CVE-2022-46670) in an Allen Bradley MicroLogix 1400, which was exploited to push WB malware. Traditional web scanning tools are ineffective here.

IronSpider's Initial Infection Example leveraged a chain of four zero-day vulnerabilities in the WAGO 750's latest firmware: a CORS misconfiguration (CVE-2022-45139) combined with an authentication bypass (CVE-2022-45138) enabled a cross-origin HTTP API call that exploited an arbitrary file upload vulnerability (CVE-2022-45140). This chain allowed IronSpider to overwrite the transpiled PLC GUI file with a duplicate page containing the malware. The attack utilized the EWS as a pivot without compromising its browser or OS. Within 3.7 seconds of viewing a malicious webpage, IronSpider was downloaded to the PLC without user notification or firewall intervention, appearing legitimate to the browser due to the circumvented browser-based rules.

Persistence

The Persistence stage (Figure 4, referenced in the talk) ensures the malware's covert presence and resilience to removal.

1. Resurrection Code in HMIs and EWSs: This strategy leverages web service workers, an HTML5 feature allowing background script execution. These workers cache resurrection code in multiple web browsers (Levels 2 and 3) throughout the ICS network. They periodically check for the removal of the primary malware payload from the PLC and, if detected, re-infect the device using web strategies similar to initial infection methods (e.g., uploading new UWPs, editing GUI files). Service workers can bypass their inherent limitations by injecting themselves into the page's fetch API, modifying proxied traffic to push new code into script tags. This method is unique to ICS due to the segregated private network and allows the malware to survive PLC hardware replacement.
2. Self-Replication via Downgraded PLC Firmware: The malware can use system website APIs to downgrade the firmware version, re-introducing known security issues. It can also store copies of itself in different sections of PLC memory for redundancy. This technique is unique to ICS as front-end code in IT typically cannot control server-side code versioning.

IronSpider's Persistence Example initially deployed to the transpiled PLC GUI file. It then used the same zero-day bugs from the initial infection to overwrite system website files, spawning new execution processes in the EWS browser. Service workers were registered in all three browsers rendering its payload: Microsoft Edge on EWS, Chromium on a remote HMI, and the WAGO microbrowser on a local HMI. These cached service workers periodically checked for the main malware payload and, if missing, re-infected the device using CVE-2022-45140 to re-upload the main malware file to the embedded web server's root directory. This strategy enabled IronSpider to survive PLC hardware replacement.

Malicious Activities

The impact of WB PLC malware is measured by its ability to sabotage machinery, abuse admin settings, and exfiltrate data (Table III, referenced in the talk).

1. Sabotage Machinery for Physical Damage: WB malware exploits legitimate system website APIs to sabotage industrial processes. Executing on the same web origin as the PLC's system website, it uses ambient browser credentials to interact with authenticated web APIs via JavaScript-initiated network requests (fetch()) or simulated user input. Specific steps vary by vendor: Allen Bradley MicroLogix 1400 exposes APIs to modify I/O values directly; Schneider TM241 allows overwriting control logic variables; Siemens S7-1200 even allows overwriting the entire PLC project via the "Restore from Backup" web API. Modifying control logic variables via web APIs does not recompile the control logic binary, thus bypassing attestation systems like PLCDefender. Adversaries require significantly less reverse engineering, deducing unsafe states by visually inspecting HMI UI screenshots.
2. Spoof HMI Values: WB malware can sabotage processes by altering values displayed in system websites and web-based HMIs. This is achieved by modifying the DOM using JavaScript (document.body.innerHTML) or overlaying fabricated displays. Stealthy malware can record sensor values in browser storage and display them during actuator compromise to hide the attack.
3. Abuse Admin Settings for Further Compromise: WB malware can modify administrative PLC configurations via web-based APIs exposed by the Web-Based Management (WBM) feature. These APIs control settings like on-device firewalls, user management, and network services. This level of control is impossible with CL malware (due to sandboxing) and extremely difficult with FW malware. With WB malware, it's easily done by calling legitimate HTTP APIs, leveraging the administrator's cookies. Table IV (referenced in the talk) lists common WBM settings and their malicious misuse, such as creating backdoor users or exfiltrating full project backups for espionage.
4. Data Exfiltration for Industrial Espionage: WB malware can utilize a public Internet connection even when the PLC is in an isolated private network. Dual-homed EWSs and remote HMIs (Levels 2 and 3) can communicate with a C2 server via allowed Level 3 protocols like DNS or HTTPS, bypassing firewalls. Generic web-based exfiltration strategies (canvas screenshots, event-listener keylogging, full DOM dumps) can intercept sensitive ICS information like physical process characteristics, plaintext usernames, and plant configuration details. This stolen data can be covertly exfiltrated using front-end network requests or URI parameters. Browser-based exfiltration is difficult for firewalls to detect because benign web applications communicate with third-party servers via encrypted protocols. The C2 stream is unaffected by on-device PLC firewalls as communication uses legitimate PLC vendor APIs. Neither CL nor FW malware can perform real-time data exfiltration in segregated industrial networks.

IronSpider's Malicious Activities Example demonstrated a Stuxnet-style sabotage using modern web technologies. It established a real-time websocket C2 channel across all three execution environments. The local HMI achieved C2 communication via a covert channel within the PLC. IronSpider modified the web-based HMIs' DOMs to display falsified sensor values, recorded previously and saved in browser local storage. It then virtually interacted with the HMI's UI to covertly change the motor speed set-point to its highest possible value. Approximately 7.4 seconds after the attack began, the emergency system tripped, indicating centrifuge damage, while HMIs displayed fake readings.

Cover Tracks

The final stage, Cover Tracks, aims to remove infection traces to impede incident response and forensics. This self-contained removal strategy is not possible with CL malware due to its user-code sandbox.

1. Delete PLC Malware Payload: Once malicious activities are complete, the malware attempts to remove its payload from PLC storage by repeating the initial infection stage using a blank or benign payload to overwrite the malware file. It also invalidates resurrection code by unregistering service workers using HTML5 browser APIs.
2. Restore from PLC Backup Image: To further remove traces, WB PLC malware can use legitimate system website APIs to restore the PLC program from a prior backup image. This overwrites set points, resets configurations, and flushes caches, giving the malware full control over the current PLC image, often the starting point for forensic investigations. This capability is unique to the ICS domain, allowing WB PLC malware to self-destruct more completely than malicious JavaScript in the IT domain.

IronSpider's Cover Tracks Example: After its successful attack, IronSpider began cleansing the PLC. This was non-trivial because the zero-day vulnerabilities had planted the malware payload in a filesystem section unaffected by factory resets. IronSpider re-used these vulnerabilities to overwrite both the system website homepage and transpiled GUI files back to their original content. Then, while still executing on any open tabs, it unregistered the service workers and flushed browser cache. Finally, it refreshed all pages, killing all execution processes.

Demo / Proof of Concept

▶ Watch: Novel Web Access infection scenario and C2 capabilities (4:55)

The evaluation unequivocally demonstrated that IronSpider is capable of sabotaging industrial processes, exfiltrating sensitive data, spoofing HMI displays, and self-destructing, all without system-level compromise of the target devices.

The experimental setup was a real-world ICS testbed, inspired by uranium enrichment centrifuges, as depicted in Figure 5 (referenced in the talk). It comprised a WAGO 750 PLC, a WAGO e!Display 7300 local HMI, and a dedicated LAN port for the industrial network. The business network included a Raspberry-Pi remote HMI and a Microsoft Windows EWS, both connected to the public Internet and dual-homed. The WAGO 750 PLC controlled a Dayton 11W366 industrial motor via a Schneider ATV12 Variable Frequency Drive (VFD) and read rotor speed via a Compact Instruments Tachoprobe A2108. A web-based HMI, developed with WAGO's WebVisu, allowed operators to view tachometer readings and change motor speed, with an emergency light indicating critical failure.

The execution and results, illustrated in Figure 6 (referenced in the talk), showed IronSpider orchestrating an end-to-end attack where the EWS served as a pivot, the PLC hosted the malware and relayed C2 messages, and both HMIs and the EWS executed the malware payload. The motor was successfully sabotaged. Crucially, neither control logic (CL) nor firmware (FW) malware alone could perform data exfiltration in this testbed due to realistic network segregation. Figure 7 (referenced in the talk) graphically represented the motor speed during the attack, showing the actual speed exceeding the critical safety threshold while HMIs displayed spoofed values. The emergency system tripped approximately 7.4 seconds after the attack began.

A performance evaluation examined IronSpider's impact and overhead. The malware consisted of two standalone JavaScript files, malware.js and resurrect.js, installed by adding a single HTML script tag. Table V (referenced in the talk) showed a total payload size of 396,214 bytes, representing a negligible 0.0092% of the PLC's filesystem. The largest component, a canvas screenshot capturer, was 193,650 bytes, highlighting the modularity of script-based malware. Client-side performance impact was measured using industry-standard metrics: Frame Rate, First Input Delay (FID), CPU Utilization, Memory Footprint, and Google Lighthouse Score. Even with an intentionally noisy configuration (aggressively capturing full screenshots every 60 seconds, recording keystrokes, and randomly interacting with the HMI), the average variation across metrics was only 3.57%. This minimal impact was virtually unnoticeable to human operators.

The generalizability across PLCs and testbeds was also explored (Figure 8, referenced in the talk). Aspects of WB PLC malware were tested against PLCs from every major ICS vendor, confirming their susceptibility to WB infections through legitimate means or zero-day exploitation (Table II). Much of IronSpider's core functionality, such as C2 communications and remote DOM interactions, was functional across all target devices. Two additional ICS testbeds were explored:

• Testbed #2: An attacker compromised an ICS network via a vulnerable edge device, targeting a password-protected Allen-Bradley MicroLogix 1400 PLC controlling a conveyor belt system. A custom UWP was used to exploit a zero-day unauthenticated XCS vulnerability via SNMP (CVE-2022-46670) to inject JavaScript. WB malware was deployed and rendered on a dedicated HMI, successfully sabotaging the industrial process by interacting with the UI. However, persistence via the service worker method was not achieved here, as the XCS vulnerability embedded snippets directly into existing HTML rather than creating new JavaScript files.
• Testbed #3: An attacker with full system-level compromise of an EWS targeted a Siemens S7-1200 in a water treatment plant. This ICS used a custom UWP and control logic attestation (PLCDefender). The attacker used legitimate Siemens Step7 software to push a malicious UWP, which did not modify the compiled CL code, thus keeping the CL digital signature intact. This UWP was rendered on a dedicated HMI and covertly controlled the water pump. In this scenario, service worker persistence was successfully achieved because UWPs can create standalone JavaScript files in Siemens devices.

Defensive Implications

▶ Watch: Four-stage lifecycle framework for Web-Based PLC malware (6:00)

The emergence of Web-Based PLC malware demands a fundamental re-evaluation of ICS security strategies. Traditional defenses, focused on control logic, firmware, and network segregation, are insufficient. The research proposes several countermeasures:

Prevention Mechanisms

1. Private Network Access Controls: Limiting communication pathways between the public Internet and private industrial Intranets is crucial to reduce Web Access infection scenarios. While browser developers are working on specifications like CORS-RFC1918, this is not a perfect solution as it doesn't apply to local HTML files or existing WB malware. Stricter firewall rules and network segmentation remain paramount.
2. Built-in Exfiltration Defenses: There is an urgent need for browser mechanisms to prevent rogue JavaScript from covertly exfiltrating sensitive data. Current Content-Security Policy (CSP) is inadequate for this specific threat, and attempts like Firefox's Confidentiality directive have been shelved. New browser-level controls are required to restrict data egress from ICS-facing web applications.
3. ICS Domain-Sandboxing: Untrusted JavaScript code, such as customer-authored User-defined Web Pages (UWPs) or custom GUIs, must be fully isolated from the PLC's system website. This could involve hosting them on a different port, utilizing the CSP sandbox directive, or implementing more robust origin separation within the PLC's embedded web server architecture.
4. Read-Only CDN with CSP and SRI: For static assets and legitimate front-end code, employing a read-only Content Delivery Network (CDN) combined with src-script directives and Subresource Integrity (SRI) could enhance security by ensuring that only authorized and untampered scripts are executed.
5. PLC-Configured Web App Firewalls (WAFs): Traditional WAFs are designed for HTTP/S traffic. New WAFs, specifically configured for ICS environments, are needed to inspect non-web PLC protocols like SNMP, Modbus, and CIP. These WAFs could detect and block malicious payloads being transferred via these industrial protocols, which are used in ICS Cross-Channel Scripting (XCS) attacks.

Detection Mechanisms

Detecting WB PLC malware presents significant challenges due to its unique characteristics:

• Traditional IDS Ineffectiveness: Traditional PLC intrusion detection systems, such as Reditus or PLCDefender, primarily focus on monitoring control logic and firmware for unauthorized modifications. Since WB malware modifies neither, these systems are effectively bypassed and will incorrectly mark the system as benign.
• Browser-Level Detection Complexity: Browser-level detection is difficult because malicious JavaScript is often intertwined with legitimate code, executes under the same origin as the PLC's admin portal, and conforms to standard browser rules. Differentiating benign, customer-authored JavaScript from malicious, attacker-authored JavaScript is an open and complex problem.
• Failure of State-of-the-Art JavaScript Malware Detectors: The research highlighted a significant gap in current detection capabilities: IronSpider was incorrectly marked as benign by four state-of-the-art JavaScript malware detectors: Cujo, Zozzle, JaSt, and JStap. This demonstrates that existing tools are not equipped to identify this specific type of web-based threat within an ICS context.

These findings underscore the urgent need for new, web-oriented detection mechanisms specifically tailored for the ICS domain, capable of analyzing client-side code execution within the unique constraints of industrial networks.

Key Takeaways

• Emergence of Web-Based PLC Malware: Modern PLCs with embedded webservers introduce a novel and highly effective attack vector, enabling malware to reside in PLC memory but execute client-side on connected browsers (EWSs, HMIs).
• Superiority Over Traditional Methods: WB PLC malware, exemplified by IronSpider, offers significant advantages over traditional control logic or firmware malware in terms of platform independence, ease of deployment, resilience, and persistence.
• Exploitation of Legitimate Web APIs: The malware leverages the PLC's own legitimate web APIs to falsify sensor readings, disable safety alarms, manipulate physical actuators, and exfiltrate sensitive data, often bypassing traditional ICS defenses.
• Widespread Vulnerability: The research confirms that PLCs from every major vendor, accounting for over 80% of the global market, are susceptible to this attack, often through zero-day vulnerabilities like those found in the WAGO 750 (CVE-2022-45137-45140) and Allen Bradley MicroLogix 1400 (CVE-2022-46670).
• Failure of Current Defenses: Traditional ICS security mechanisms (e.g., control logic attestation, network segregation, existing JavaScript malware detectors) are largely ineffective against WB PLC malware, as it operates within a legitimate web context.
• Urgent Need for Web-Oriented ICS Security: A re-evaluation of ICS security paradigms is critical, necessitating the development and implementation of new web-oriented prevention (e.g., domain-sandboxing, enhanced browser exfiltration defenses, ICS-specific WAFs) and detection mechanisms to address this evolving threat.

About the Speaker(s)

Ryan Pickren is a security researcher, as evidenced by his detailed technical presentation on novel PLC malware. His work focuses on identifying and exploiting vulnerabilities in industrial control systems, particularly those related to the emerging attack surface presented by embedded webservers in PLCs. His research, including the development of the IronSpider prototype and the discovery of multiple zero-day vulnerabilities, highlights his expertise in both web security and ICS environments.