On Ladder Logic Bombs in Industrial Control Systems

Abstract

In industrial control systems, devices such as Programmable Logic Controllers (PLCs) are commonly used to directly interact with sensors and actuators, and perform local automatic control. PLCs run software on two different layers: (a) firmware (i.e. the OS) and (b) control logic (processing sensor readings to determine control actions).

In this work, we discuss ladder logic bombs, i.e. malware written in ladder logic (or one of the other IEC 61131-3-compatible languages). Such malware would be inserted by an attacker into existing control logic on a PLC, and either persistently change the behavior, or wait for specific trigger signals to activate malicious behavior. For example, the LLB could replace legitimate sensor readings with manipulated values. We see the concept of LLBs as a generalization of attacks such as the Stuxnet attack. We introduce LLBs on an abstract level, and then demonstrate several designs based on real PLC devices in our lab. In particular, we also focus on stealthy LLBs, i.e. LLBs that are hard to detect by human operators manually validating the program running in PLCs.

1 Introduction

Industrial Control Systems (ICS) are computer systems that typically control physical processes that relate to power, water, gas, manufacturing and other critical infrastructure. ICS and Supervisory Control and Data Acquisition (SCADA) systems rely on local programmable logic controllers (PLCs) to interface with sensors and actuators. While PLC devices are available from a range of manufacturers, they are all commonly programmed with the same set of programming languages based on IEC 61131-3. In particular, the IEC 61131-3 standard [7] contains ladder logic, functional block diagram, and sequential text as different languages that are used together to define logic to run on the PLCs. The logic is then interpreted by the firmware running on the PLCs. Modern PLCs provide security mechanisms to allow only legitimate (e.g., signed) firmware to be uploaded. In contrast, logic running on the PLCs can typically be altered by anyone with network or local USB access to the PLC. This setting is the main difference to malware scenarios in traditional corporate IT environments, where the injection of attacker code is usually significantly harder.

Recently, the security of Cyber Physical Systems (CPS) and related systems has gained a lot of attention [4, 13, 21,22,23]. In particular, CPS such as critical infrastructure including power grids, nuclear power plants, and chemical plants are threatened. In CPS, physical-layer interactions between components have to be considered as potential attack vectors, in addition to the conventional network-based attacks.

In this work, we introduce ladder logic bombs (LLBs), i.e. malware written in ladder logic (or one of the other IEC 61131-3-compatible languages). LLBs consist of logic that is intended to disrupt the normal operations of a PLC by either persistently changing the behavior, or by waiting for specific trigger signals to activate malicious behavior. In particular, the LLBs could lay dormant and hence hidden for a very long time until a specific trigger is observed. Once activated, the LLB could replace legitimate sensor readings that are being reported by the PLC to the SCADA system with manipulated values. We introduce LLBs by classifying their purpose and action, and demonstrate several constructions based on real PLC devices in our lab.

We implemented and tested our attacks on a real-world ICS (the SWaT testbed, see Sect. 4). In particular, we focused on stealthy LLBs, i.e. LLBs that are hard to detect by human operators manually validating the program running in PLCs. We provide a classification of logic based attacks, such as the ones performed by Stuxnet [5].

We summarize our contributions as following:

• We analyzed firmware updates on the target platform to detect vulnerabilities.

• We identify the issue of logic manipulations on PLCs, and introduce the concept of ladder logic bombs (LLBs).

• We present a range of LLB prototypes, in particular ones that attempt to hide from manual logic code inspection.

The structure of this work is as follows: In Sect. 2, we introduce CPS systems, PLCs, and IEC 61131-3 in general. We propose our Ladder Logic Bomb concept in Sect. 3, and present example implementations in Sect. 4. Related work is summarized in Sect. 6. We conclude the paper in Sect. 7.

2 Background

In this section, we will introduce some of the salient properties of industrial control system (ICS) networks that we have found so far. In addition, we will briefly introduce Ladder Logic programming language and the tools necessary to interact with such PLCs.

2.1 ICS

In the context of this work, we consider ICS that are used to supervise and control system like public infrastructure (water, power), manufacturing lines, or public transportation systems. In particular, we assume the system consists of programmable logic controllers, sensors, actuators, and supervisory components such as human-machine interfaces and servers. We focus on single-site systems with local connections, long distance connections would in addition require components such as remote terminal units (see below). All these components are connected through a common network topology.

Fig. 1.

Example local network topology of a plant control network.

2.2 Ladder Logic and Studio 5000

A Programmable Logic Controller (PLC) is an industrial computer system that continuously monitors the state of input devices and makes decisions based on a custom program to control the state of output devices. PLCs are widely used in industrial control systems (ICS) for handling sensors and actuators, mainly because of their robust nature and ability to withstand harsh conditions including severe heat, cold, dust, and extreme moisture. Considering their widespread usage and important nature of tasks handled by PLCs, their security against malicious manipulation is critical.

PLC programs are typically written in a special application on a local host (personal computer), and then downloaded by either a direct-connection cable or over a network to the PLC. The program is stored in the PLC in a non-volatile flash memory. While details differ for platforms from alternative vendors, it might be required to enable remote change of control software on the PLC through a physical switch (i.e., program mode on ControlLogix devices). We observe that due to convenience, in practical systems PLCs are often kept in that setting to allow easy remote access. In addition, any attacker with physical access is able to change the switch setting easily. For that reason, we assume that remote or local reprogramming access is possible in the remainder of this work.

IEC 61131-3 is an open international standard [7] for PLCs that defines two graphical and one textual programming language standards for PLCs:

• Ladder Logic Diagrams (graphical)

• Functional block Diagram (graphical)

• Structured Text (textual)

The most popular of those languages is Ladder Logic Diagrams. The main intuition behind this Ladder Logic Diagrams is to provide a system-wiring diagram abstraction similar to electro-mechanical relays. Ladder logic is more of a rule-based graphical language implemented by rungs, rather than traditional procedural-based language. A rung in the ladder represents a rule. They are called “ladder” diagrams because they resemble a ladder, with two vertical rails (supply power) and as many “rungs” (horizontal lines) as there are control circuits to represent.

“Studio 5000” is a software product of Rockwell Automation that provides an environment to develop a range of elements for a control system, for operational and maintenance use. Its major element is the Studio 5000 Logix Designer application, formerly (RSLogix 5000), software to program Logix5000 controllers.

Another tool called RSLinx is used to establish USB-based communication between PLCs and a host PC running Studio 5000. RSLinx is a Windows based software package to interface with a range of ICS and automation hardware. In this paper, we used Allen-Bradley PLCs (ControlLogix 5571) with Studio 5000 v21.00. It is important to note that for different PLCs, different versions of RSLinx and Studio 5000 have to be used.

3 Ladder Logic Bombs

In this section, we present our proposed concept of ladder logic bombs. In particular, we noticed that while changes to the firmware of PLCs are made more difficult by digital signatures, the actual logic that is executed on the PLCs is not protected by such a measure. In addition, the lack of security checks/authentication before downloading new logic onto PLCs is a cause of major concern. An attacker can exploit this by either gaining physical access to the PLCs or over the network, and can download custom (malicious) logic onto PLCs which can compromise the system. Next, we discuss potential attack scenarios and goals, which can be achieved through this vulnerability.

3.1 System and Attacker Model

In this work, we assume that the attacker is able to access PLCs in an industrial control system either remotely via the network, or physically. As we will show, commonly such access will allow the attacker to read and modify the programming logic of the PLCs without any authentication. The attacker is assumed to have access to the respective software required to download and upload logic configurations to the PLC (e.g., Studio 5000 for ControlLogix PLCs).

The goals of the attacker can range from achieving a Denial of Service (DoS), to changing the behavior of the PLCs, or to obtain data traces of sensor and control messages processed by the PLC. In order to perform these attacks, the attacker just needs access to the PLC system once, making such attacks all the more dangerous. The attacker could also have sporadic (physical) access to the PLC. For example, the attacker only has access to the PLC once a week (because he is a regular contractor). In these events, the attacker can trigger any behavior changes (i.e. trigger his ladder logic bomb) at a point unrelated to his access time (e.g., to hide correlations to his access).

The system we consider in this setting is very generic and can be described as follows: a PLC in an industrial control system which uses IEC 61131-3 languages for the logic, and can be re-programmed as described above. It is connected to sensors and actuators of a critical process. Operators of the plant configured the logic of the PLC at design time. Though they continuously monitor the status of these PLCs, they seldom need to change the logic configuration of the already operational system. They are also able to manually download the logic to inspect it, if required. Although we will briefly discuss a network-based detection mechanism using an intrusion detection system later, such a solution will not be able to detect changes by a local attacker. For that reason, we do not focus on IDS in this work. In addition, physical layer prevention mechanisms (camera, fences, etc.) are out of scope of this work.

We do not consider an attacker that is able to attack the operator’s machines (as it was the case in Stuxnet), or able to manipulate network traffic while it is being transmitted. In particular, if the attacker was able to compromise the operator’s machine, then the operator would not be able to verify any code reliably. Such an attacker could be addressed by using a trusted computing platform, which we consider out of scope for this work. The attacker model does also not consider insider attacks (e.g., an attacker who might be regular contractor/employee with authorization to access and modify the PLC logic).

3.2 Bomb Classification

Ladder logic bombs can be classified broadly by two criteria (as shown in Fig. 2). LLBs can be classified according to their activation and triggering. They can either be externally triggered by giving a certain input. Alternatively, they can be triggered by internal logic (system states, specific instructions or data, clock, etc.)

Fig. 2.

Ladder Logic Bomb (LLB) classification

LLBs can also be classified according to the alteration they incur onto the existing PLC system. They can add or remove certain functionality in the existing logic (modify function). These bombs can also alter the system values such as system date/time, timezone, wall-clock time, or similar (modify system). Finally, these can also be used for data exfiltration and transmitting crucial system data to a spy node (transmit information).

Together, those classifications now describe more specific LLBs. For example, a LLB that turns off a pump at 12 AM would be classified as internally activated function modification LLB.

Fig. 3.

(photo source: http://itrust.sutd.edu.sg).

Overview of SWaT testbed

3.3 Triggering

Here, we describe the different triggering mechanisms that can be used with ladder logic bombs.

Triggering at a particular Input: The bomb could be set off when a pre-determined input is detected. For example, we are targeting a water treatment ICS for our experiments (see Sect. 4.1). The target PLC is receiving inputs about the water level in one of the tanks from its corresponding level sensor. The bomb could be set off when a particular level is reached in the tank.

Triggering Sequence: The bomb could also be triggered when a particular trigger sequence is detected. This would potentially make the bomb more difficult to detect, as none of its effects would be visible until the particular sequence is detected as input. This can be achieved by implementing a finite state machine (FSM) using latches.

Timer: The bomb could also be set off using a timer. This would make the LLB like a real world time bomb, which sets into motion when the timer has finished its count sequence. Using nested TON timers, it is possible to implement count sequences which will last days.

Specific Internal Condition: The bomb could be triggered when a particular internal state is achieved. This particular triggering scheme requires the attacker to have complete knowledge and understanding of the logic on the PLCs. When a particular state variable, for example a fault code, is set, the bomb could be set off and the payload logic is executed.

3.4 Hiding LLBs in PLC Logic

The naïve approach to detect any modifications in the original logic (in our case, the LLBs) would be to download the control logic from PLC devices, and manually inspect them for code changes. In particular, engineers familiar with the plant operations might be able to read through the code and detect malicious changes. While that approach might be feasible for small sites and very simple logic, we will show in the following section that there are several options for the attacker to hide the malicious payload within the logic to make it harder to detect by such manual inspection.

4 Implementation

In this section, we describe in detail the construction of ladder logic bombs and demonstrate how they can be used to disturb the functioning of ICS.

4.1 SWaT Testbed

The experiments were conducted on an industrial control system testbed, called SWaT, located at the Singapore University of Technology and Design. Secure Water Treatment, as depicted in Fig. 3, is a fully functional (scaled down) water treatment plant. SWaT was constructed exclusively as platform for research on cyber physical system security. The water treatment process is partitioned into six stages, starting with raw water in Tank 1 to filtered output water in Tank 6. Each stage is controlled by an independent PLC which determines control actions using data from sensors.

Sensors values and actuator commands are communicated to and from a PLC via a plant network. The system also contains monitors to view and ensure system states are within acceptable operational boundaries. Data from sensors are available for inspection on the Supervisory Control and Data Acquisition (SCADA) workstation and recorded by the Historian for subsequent analysis.

4.2 Attack 1: DoS Using Add on Instructions

The Denial of Service (DoS) is a potential attack goal to inflict (most often financial or reputation) damage on critical systems. In a DoS attack, the attacker temporarily or permanently slows or stops correct operations of a system. On the Internet, (distributed) DoS attacks are often achieved by creating massive amounts of traffic that overload communication links or servers. As PLCs control the action of sensor and actuators in the system, their operational availability is often critical [12]. If the PLC is incapable of controlling the actuators, it can have disastrous consequences (e.g., lead to the loss of control of heavy machinery in an automobile assembly plant).

Goal: In this setup, the goal was to launch a DoS attack on one of the PLCs in a water treatment plant.

Construction: This has been achieved by implementing an infinite loop as the bomb payload. The trigger mechanism for this LLB is when a particular input is received. Similar to Stuxnet [5], the trigger check condition lays on top of the actual logic, which always stays on to check if the particular input has been received. As soon as the desired trigger input is received, the LLB springs into action.

Concealment: The actual malicious logic has been hidden inside an Add-On Instruction. A new instruction has been created, which is very similar in its construction to the real ADD block, with similar inputs: 2 sources A and B and an output: Destination. It has also been named suitably (ADD_A) to disguise well with a real ADD block. From the top overview of the ladder logic (which contains many rungs), this looks just like any other ADD block on one of the rungs. But inside this add-on instruction, the real bomb (an infinite loop) is defined, and that adversely affects the PLC operation. More details about this can be found in Fig. 4.

Fig. 4.

Malicious Add-On instruction

4.3 Attack 2: Manipulation of Sensor Data Using Subroutines

Another important function of the PLCs in ICS (in addition to controlling the actuators) is reading data from sensors. That data can be critical information about the process and system. Using the data, it is possible to derive the current state of the process, which is used by the PLC to determine appropriate control actions. Thus, tampering with sensor data can cause systems to fail [11].

Goal: The goal for this attack was to manipulate sensor readings coming from the remote IOs (RIOs in Fig. 1) to the PLC.

Construction: Since this is proof-of-concept, we decided to manipulate the sensor values and increase them by a constant offset (we arbitrarily chose four). As result, the LLB payload is a simple ADD block which takes the real sensor values and increases them by four, and stores them back into the same tag. However, a more complex triggering mechanism was used in this attack. In particular, the LLB is triggered when a complete trigger sequence is detected. This has been achieved by implementing a finite state machine using latches (see Fig. 5).

Concealment: For this attack, we also used A different hiding technique. By inspecting the actual logic of the PLC in the water treatment plant, we observed that the logic was calling a large number of subroutines. We assume the subroutines were called that way to maintain good readability of the ladder logic by the maintainers. However, that structure with large number of subroutines can be leveraged by the attacker to hide the LLB. We tested this exploit by hiding a trigger subroutine that gets executed every cycle of the ladder logic (see Fig. 6).

Fig. 5.

Inside the exploiting subroutine

Fig. 6.

Overview of the logic with the exploiting subroutine

4.4 Attack 3: Data Logging Using FFLs

The attacks discussed above are openly causing damage or malfunctions, and their effects can be observed as soon as triggered. However, there are another class of LLBs which can be equally harmful but are harder to detect. In particular, such LLBs could be used for data logging and exporting sensitive information about the system.

Goal: The goal of this attack is to achieve stealthy data logging of sensitive information about the plant.

Construction: The data logging is achieved by using a FIFO buffer which reads data into an array. The FFL block has been used for this purpose. As shown in Fig. 7, the FFL block stores the tag PB_LT_Seq which contains sensitive information about the count sequence used to determine state of the plant. Those values are stored into the array2 and are converted into .csv format and stored on the SD card in the PLC. Staying within our attacker model, an attacker who has sporadic access (physical access to PLCs) to the plant can come in, read these values stored on the SD card. Then, insert this card back into the PLC and leave. The trigger sequence for this could be a simple timer, thus ensuring data logging after ‘x’ days of plant operation.

Concealment: This LLB can again be concealed either inside an Add-On instruction or as a subroutine. It can also be left inside the main logic flow, since this LLB contains just one extra rung, making its manual detection difficult in large and complex code.

Fig. 7.

Data logging in a FIFO buffer

4.5 Attack 4: Trigger Major Faults on PLC

We now discuss another attack which is similar in effect to the DoS attack.

Goal: The goal is to trigger major faults on the PLC which causes its processor to halt and which cannot be fixed by a hard reset.

Construction: Here we managed to cause a major faults on the PLC. In particular, we used invalid array subscripts and a stack overflow. The stack overflow was achieved by implementing a recursive subroutine call to itself. This caused the stack storing the return pointer to overflow, halting the process and crashing the PLC (Fig. 8).

Concealment: These LLBs can be concealed within an Add-On instruction or inside a subroutine.

Fig. 8.

Stack overflow

4.6 Analysis of Attacks

Ideally, there would be a metric to measure the stealthiness of LLBs, that would indicate how hard different LLBs are to discover. So far, we have not found a good way to measure that property. In the following, we instead use the relative additional lines of code (RALOC) to measure the stealthiness. In particular, the increase of lines of code in the logic can also lead to increased memory consumption at runtime. We observed that there are two types of memory that is used by a ladder logic program: I/O memory and Data & Logic memory. As part of our analysis, we measured the difference (increase) in memory of the original logic when malicious ladder logic bombs were added. It was observed that there was no increase in the I/O memory of the PLC at all, which is primarily because no new inputs/outputs were created to trigger or apply the ladder logic bombs discussed above. The only increase observed was in the data and logic memory, which is also marginal, as depicted in Table 1. Important thing to note is that Table 1 entries are taken at particular attack scenario and the size of Attack 3 (data logging) will depend on the amount of data that is logged. As result, the RALOC metric increases, and the modifications might become more visible.

To mitigate that effect, it is best to save the data on the SD card and then flush the arrays so that they can be re-used if more data needs to be logged.

Table 1. Comparison of attacks performed

5 Countermeasures

In this section, we discuss potential countermeasures against LLB attacks. In particular, we discuss (a) network-based countermeasures, and (b) centralized validation of running code.

In the following, we assume that the countermeasures are retro-fitted into an existing industrial control system. In particular, we assume it is not possible to change the PLCs themselves. If we could change the way logic updates are applied to PLCs, it would trivially be possible to introduce user authentication (e.g. with username/password, or public key-based), or cryptographic signatures for logic updates. The PLC would then only accept the logic code update if the user is successfully authenticated, or the authenticity of the update has been validated.

5.1 Network-Based Countermeasures

If an intrusion detection system (IDS) is already used in the network to monitor traffic for spreading malware or other malicious traffic, then that IDS could potentially be used to identify the specific traffic related to logic updates on PLCs connected to the network. If unauthorized logic updates over the network are observed, an alarm could be raised. A similar IDS is proposed in [6], where the authors model periodic communication between HMI and PLCs using a deterministic finite automata. The system flags anomalies if a message appears out of position in normal (general) sequence of messages. If the IDS is configured to operate as intrusion prevention system (IPS), the offending traffic could even be dropped in real time.

The problem with this proposal is related to the identification of authorized logic updates. As we cannot change the traffic generated by the respective software, there is no way to embed specific authentication information. Thus, we can only use information such as IP source address (supposedly related to the authorized person), which is not ideal (as it can be spoofed).

5.2 Centralized Logic Store

Our second proposal is based on two components: (a) a centralized logic store (CLS) of the latest version of logic running on all PLCs of the ICS, and (b) a tool to periodically download currently running logic from the PLCs, and to validate that against the “golden” copy from the CLS. An overview of our proposed system can be found in Fig. 9.

Fig. 9.

Centralized logic store based countermeasure

Submission of golden samples: All authorized engineers are required to submit the most recent version of logic for each PLC to the CLS when they change the logic running on the PLCs. To do so, they can use a simple application that requires them to identify the respective logic file, the target PLC, and their credentials. That application will then use the credentials to establish an authenticated secure channel to the CLS (e.g. using TLS), and then upload the latest logic version to the CLS (e.g. using HTTP over the established TLS session).

Periodic Logic Validation: We have implemented a python-based tool to manually and periodically validate the logic. The user first exports ladder logic to a .L5K file (sequential text) on the local machine using Studio 5000. Next, our tool parses the .L5K file and extracts a unique serial number corresponding to the logic. Then, the tool connects to the CLS where the correct golden logic is searched by using Beautiful Soup parser (BSP). BSP is a python library to parse HTML and XML pages, in our case BSP parse CLS and look for all .L5K file followed by our parser which looks for correct golden logic by identifying the unique serial number.

Then, the tool performs a comparison between the logic found on the PLC, and the golden sample. If differences are found, they can be visualized to a human operator using standard functionality provided by tools such as diff. The algorithm below summarizes the whole process.

6 Related Work

General Threats to ICS. It has been observed over the years that process control systems are vulnerable to various exploits with potentially damaging physical consequences [2, 14, 20].

In [19] Morris and Gao discuss different attacks such as measurement injection, command injection, denial of service, etc., on SCADA control systems which use the MODBUS communication protocol. Much like the rest, this study is again restricted to exploiting the network layer to attack the PLCs. Therefore, it is necessary to analyze control logic vulnerabilities, which can be manifested through malicious logic additions.

Stuxnet. In 2010, Stuxnet [5] caused a radical shift in focus for security of such control systems by demonstrating practical exploitation of the control logic in these devices. This resulted in increasing focus on security aspects of PLCs and their control logic [1, 8, 9]. In [8], Karnouskos discuss Stuxnet and how it managed to deviate the expected behavior of PLC. In [9], Kim discuss the cyber security issues in nuclear power plants and focused on stuxnet inherited malware attacks on control system, and its impacts in future along with its countermeasures.

Protocol-based attacks. The authors of [1] discuss replay, reconnaissance and authentication by-pass attacks. These attacks can be performed by sending probe requests or by examining the ISO-TSAP conversation and authenticating oneself by generating packets with same hash, in turn, achieving access to PLC logic. All these attacks are focused on exploiting the communication protocols to gain access to PLCs.

In [18], the authors investigate vulnerabilities of industrial PLCs on firmware and network level, leaving out any analysis on logic level exploits. In this work, we provide a consolidated study on logic layer manipulations and provide logic level safeguarding methods, unlike the network based security (e.g., firewall, VPN security and secured layered architecture) methods proposed in majority of the papers above.

Control Logic Manipulation. In [15], the authors propose a PLC malware capable of dynamically generating a payload based on observations of the process taken from inside the control system. The malware first gathers clues about the nature of the process and the layout of physical plant. Dynamic payload is then generated to meet the specific payload goal. However, the authors assume that an attacker must be insider or have prior knowledge of the targeted system. That dependency is worked upon in [16], which proposes a tool to automatically determine semantics of the target PLC, minimizing the need for prerequisite knowledge of target control system. This work however does not go into details of malicious logic construction on ladder logic or any other IEC 61131-3-compatible language and focus mainly on network layer attack.

Countermeasures. In general, attempting to validate the authenticity of the root file system or files/directories is not a new concept. In [10], Kim and Spafford proposed a monitoring tool “Tripwire”. It monitors the Unix based file system and notifies the system administrator in case a corrupted file or alteration is detected. In contrast to Tripwire tool (which uses interchangeable signature subroutines to identify changes in file) our proposed CLS based countermeasure compares the local instance of a file with its authorized one. Another important point to note here is that the Tripwire tool is host based, used for unix based file systems whereas proposed countermeasure is used in respect to PLC logic file (.L5K) extracted from Studio 5000 tool.

We found a number of works focused on development of countermeasure techniques to safeguard PLCs and other components of industrial control systems. In [3], a sequence aware intrusion detection system (S-IDS) is proposed. The IDS focuses on detection certain sequences of events (e.g. sensor readings or control actions) that are harmless on their own, but can lead to unwanted consequences if chained together. Other attack detection methods for PLCs are found in [17, 24]. In [24], the authors propose an approach based on symbolic execution of PLC code along with control model checking to automatically detect the malicious code running on the PLC. In [17], a Trusted Safety Verifier (TSV) is implemented on a Raspberry PI set-up, placed in between the control system network and the PLC as a bump-in-the-wire to intercepts all the controller code and validate it against all the safety properties defined by process engineer. This requires additional hardware set-up to function. In this paper, we intend to propose countermeasures which can be very easily used with the traditional (existing) industrial control system architecture and have least dependency on PLC internals (construction and interface internals).

7 Conclusion

In this paper, we have introduced the term ladder logic bombs to discuss the problem of logic malware for PLCs, such as modifications performed by Stuxnet [5]. Contemporary vulnerabilities study for such devices usually do not include analysis on control logic level, which is an important source of attacks as demonstrated in this work. We analyzed vulnerabilities in the firmware running on PLCs and depicted case studies and attack scenarios in real-time on actual PLCs to inflict damage on industrial control systems. All the tests were conducted on a real world ICS, unlike majority of the theoretical works presented in the literature so far. Finally, a centralized logic store based countermeasure technique was proposed and implemented, that can detect logic level based attacks effectively.