Busting Modbus: Simulation and exploitation of

PLCs

Evan Dyeetdye[at]cs.unm.edu

Whit Schonbeinschonbein[at]cs.unm.edu

May 4, 2016

Abstract

In this paper we investigate attacks focused on Modbus, an old-yet-widely-used protocol for communication in SCADA contexts. We developa simulated PLC using this protocol (modbussim); a unified attack toolfor performing response injection and reconnaissance attacks (modbuster);and show the latter can successfully execute several attacks against theformer. Furthermore, we show how an ARP man-in-the-middle attackis able to extract PLC data from Modbus packets traveling across thenetwork.

1 Introduction

In 2010, the Stuxnet virus dramatically exposed the vulnerability of modernindustrial control systems (ICS): suspected to be of American-Israeli origin,Stuxnet attacked the programmable logic controllers (PLCs) used to manageIranian uranium enrichment centrifuges, reporting data back to its creators,and crippling the efficiency of extraction. As Stuxnet vividly demonstrates, it ishard to overemphasize the importance of securing ICSs for national and corpo-rate security: well-executed attacks could disable the power grid, compromisesensitive information or intellectual property, and cause debilitating economicconsequences.

In supervisory control and data acquisition (SCADA) environments, PLCsare responsible for directly interacting with machinery, e.g., centrifuges, robots,assembly lines, etc. Analog and digital information from sensors comes into thePLC and is stored in ‘coils’ (i.e., single bits) and ‘registers’ (i.e., often arraysof 16 bit integers). A looping, constantly running program reads these valuesand issues the appropriate control signals to the machinery, thereby closing thecontrol loop.

Each PLC is also connected to a ‘master controller’, e.g., a Windows machinerunning an application for interacting with PLCs, provided by the manufacturer.The master is able to monitor (i.e., read) current register data, and influencethe behavior of the PLC (and hence the machinery) by writing to registers.

1

For instance, to shut down an assembly line, the master might write 0x0 to adesignated register; when that register is read by the PLC program, the programswitches to issuing shutdown commands to the machinery it controls.

Communication between master and PLC is accomplished through a varietyof protocols, such as Modbus1, S7/PROFINET2, and DNP33. Unsurprisingly,since Stuxnet there has been a flurry of work on the security of these protocols- all of which traditionally transmit in plain text.4 For example, Beresford [2]and Ben Aloui [1] explore the exploitation of the S7 protocol, including pass-ing the hash (for password-protected PLCs), decrypting Siemens PLC firmware,and performing code injection. Dong Jin, Nicol, and Guanhua Yan [4] demon-strate the feasibility of a buffer overflow attack on a DNP3 SCADA network,East et al. [5], offer a taxonomy of DNP3 attacks based on their targets andthreat categories, and Mallouhi et al. [8] provide a testbed for detecting attacksexploiting the DNP3 and Modbus protocols.

In this paper, we investigate the exploitation of the Modbus protocol. Inparticular, Morris and Gao [11] provide a taxonomy of three types of Mod-bus attack: reconnaissance attacks are those that attempt to gain informationregarding the architecture and function of a PLC; response injection attacksmanipulate the contents of Modbus packets, thereby delivering erroneous in-formation regarding the state of attached devices, either to the PLC or to themaster controller; and denial of service attacks attempt to make communica-tion with a PLC impossible. In this paper, we (i) implement a simulated PLC,modbussim, (ii) execute three response injection attacks against the simulationusing our modbuster tool, and (iii) perform a pure reconnaissance attack usingARP poisoning and a custom Bro script.

The structure of the paper is as follows. In section 2, we describe the Modbusprotocol, survey the research platforms we considered, and describe our PLCsimulation. In section 3 we present our attacks as a series of ‘challenges’ ofincreasing difficulty. Finally, we conclude (section 4) by summarizing our resultsand sketching future directions of research.

2 Methods

The Modbus protocol was developed in 1979 for serial communication with PLCsgoverning automobile assembly lines; it was subsequently extended to work overTCP/IP (i.e., ‘Modbus over TCP’) [10], [9]. Despite its age, it is still widely de-ployed: as recently as March 2016, developer Matthew Garrett reported findingModbus being used to control the lighting, curtains, and television at a swankhotel.5

1http://www.modbus.org/2http://us.profinet.com/technology/profinet/3https://www.dnp.org/4To our knowledge, current PLCs from Siemens utilize a proprietary encrypted version of

S7.5http://mjg59.dreamwidth.org/40505.html. After establishing his ability to control devices

in other rooms, Garrett concludes, “We’re doomed.”

2

Figure 1: The Modbus PDU and encapsulating ADU. From [9].

Figure 2: The Modbus communication sequence. From [10].

The structure of the protocol is straightforward. PLCs support approxi-mately 43 functions that can be requested by a master controller, e.g., ‘readfrom register i’ and ‘write to register j’. Each function is assigned a functioncode (e.g., 0x03 corresponds to ‘read from holding registers’), so the core proto-col data unit (PDU) consists of (i) a byte containing the function code, and (ii)zero or more bytes containing data to be written to the PLC. For TCP/IP com-munication, a Modbus application protocol (MBAP) header is appended, whichspecifies (among other things) the size of the PDU (figure 1). The resulting ap-plication data unit (ADU) is then wrapped in a TCP packet for transmission.

Communication with a PLC via Modbus always elicits a response from thePLC (figure 2). This response contains either (i) requested information (in theevent of a read), (ii) an acknowledgement of the success of the communication,or (ii) an exception code (in the event of an error). The fact the protocolrequires PLCs to always respond is useful for reconnaissance and for avoidingfalse positives when port scanning (section 3.5).

We considered a variety of possible platforms for conducting our experiments:

1. Physical PLCs. The ideal research platform consists in actual physicalPLCs.6 However, this option was not feasible because of (i) cost, (ii)setup overhead (e.g., what do we hook it up to?), and (iii) the models wesurveyed shipped with a proprietary encrypted S7 protocol.

6E.g., http://velocio.net/, http://w3.siemens.com/mcms/programmable-logic-controller/

3

2. Simulated PLCs. An alternative to physical PLCs is simulated PLCs,and we found several currently available. The PLCLogix simulator7 offersfull support for ladder logic programming and interactive 3D animationsof PLCs controlling various systems. However, the 15 day free trial istoo short for this project, and the simulation is explicitly for training(e.g., ladder logic programming); it is not clear the simulation includesexternal communication through any protocol. In contrast, the ModbusPLC Simulator8 is free and has Modbus support. However, while wedid use this simulation for some testing during development, it does notprovide the precise functionality we are looking for: we want to modelthe conditions under which controlled machinery fails, and this is notsupported by this simulator.

3. Rolling our own simulation. The final option is to create our ownsimulation. We found several libraries supporting the Modbus protocol,including pymodbus (for Python) [12] and libmodbus (for C) [7]. In thefollowing subsection, we describe our simulation, implemented in C usinglibmodbus and pthreads.

2.1 The modbussim simulation

modbussim simulates an n-register PLC connected to a centrifuge (figure 3).The PLC implements a control loop maintaining the RPM of the centrifuge ata particular target value (default = 25000 RPM). Specifically, (i) a sensor writesthe current measured RPM to a designated register in the PLC; (ii) the PLCprogram reads the value of this register; and (iii) if the value is above or belowthe target, a command is sent to the centrifuge instructing it to slow down orspeed up by some (fixed) amount.

The simulation itself consists of two threads. One thread utilizes libmodbus,and is responsible for handling Modbus communication requests arriving fromoutside the simulation (i.e., from a master controller). The second thread isresponsible for modeling the centrifuge and PLC program logic.9 The codefor modbussim (and all other tools described in this document) is available onGitHub, at https://github.com/71whit/modbussim.

On a typical run of modbussim, the user simply tells the simulation how manyregisters to use, up to the limit established by the Modbus protocol (123). Thesimulation randomly selects a register to be the RPM register, and populatesthe remaining registers with random values. At each iteration of the simula-tion loop, the RPM register is updated with the current sensor value from thecentrifuge, and if necessary, the PLC program issues a command to adjust itsspeed. Furthermore, the values of the remaining registers are updated by arandom value in the range ±1024; this makes reconnaissance attacks more in-

7https://www.plclogix.com/8http://www.plcsimulator.org/9A third thread provides profoundly annoying sound effects representing the speed of the

centrifuge. This thread is disabled by default.

4

Figure 3: The architecture of the modbussim simulation.

teresting. Finally, Modbus communications are handled concurrently by thecommunication thread.

The simulation continues to run until terminated by the user, or when theactual speed of the centrifuge exceeds a threshold (e.g., 30000 RPM), at whichpoint the centrifuge tears itself to shreds. Figure 4 depicts a typical run ofmodbussim using default parameters; after displaying the parameters being used,the simulation reports the RPM of the centrifuge followed by the RPM valuepresent in the RPM register. Figure 5 shows the available command line options.

5

Figure 4: A typical modbussim run using default parameters.

Figure 5: modbussim command line options.

6

Figure 6: The testbed. One Raspberry Pi runs an instance of modbussim, andattacks are launched from the other.

3 Attacks and Results

As noted in section 1, we pursued three types of attack against our simulatedPLC: (1) pure response injection attacks (section 3.3), (2) combined recon-naissance and response injection attacks (sections 3.4 and 3.5), and (2) purereconnaissance attacks (section 3.6).

3.1 Hardware

The hardware for testing these attacks consists of two Raspberry Pis runningArch Linux (figure 6) networked via either (i) a Netgear N600 router plus aTP-Link 4-port switch, or (ii) a Netgear WNR3500 router. For the first threeattacks (subsections 3.3-3.5), one Raspberry Pi runs an instance of modbussim,and attacks are launched from the other. For the final attack (subsection 3.6),one Raspberry Pi runs an instance of modbussim while the other monitors theregisters of the simulated PLC by issuing Modbus read requests; the (reconnais-sance) attack is then launched from an Asus Eeee netbook running XubuntuLinux.

3.2 modbuster

modbuster is a tool for performing Modbus attacks, written using libmodbus

and pure C. This allows it to be dropped onto just about any platform, whetherrunning a Linux OS, Mac OS, or Windows OS; this includes Linux based routers.Additionally, if the program is found on a compromised machine, decompilationtechniques are not particularly useful. modbuster exploits the delicate nature

7

of the PLC-centrifuge (or other device) control loop by writing erroneous valuesinto specifically targeted registers of the PLC. The writing of this erroneous datais repeated until connection to the PLC is lost, presumably once the centrifugehas been damaged. Further details of modbuster are found in the remainingsections for attacks 1 through 3. The code for modbuster can be found in themodbussim GitHub repository: https://github.com/71whit/modbussim.

3.3 Attack 1

The first attack is a ‘pure’ response injection attack, as it involves no reconnais-sance: the goal is to ‘blow up’ the centrifuge given that the attacker alreadyknows (i) the IP address of the PLC, (ii) the port it is using for communication,and (ii) the offset of the register containing the data we want to corrupt.

This is accomplished by bombarding the RPM register with Modbus ‘writeregister’ instructions, overwriting the correct RPM data with a value that isbelow the target speed (in this case, zero). The PLC program then believesthe centrifuge is running slow, and issues successive commands to increase itsspeed. Eventually, the failure threshold is reached, and the centrifuge ‘explodes’(figure 7).

8

(a)

(b)

Figure 7: The first modbuster attack successfully destroys the centrifuge. (a)shows the runtime options used for the attack; the attacker explicitly specifiesthe IP, port, and register to target. (b) shows the actual RPMs of the centrifugespiraling out of control as the PLC incorrectly indicates the centrifuge is notspinning.

9

Figure 8: modbuster successfully determines which register to attack, and thenperforms response injection until the centrifuge explodes.

3.4 Attack 2

The second attack combines reconnaissance with response injection: the chal-lenge is to ‘blow up’ modbussim given that the attacker knows (i) the IP addressof the simulated PLC, (ii) the port it is using, but not the register containingthe data we want to corrupt.

This is accomplished by reading each register of the PLC. If the register’svalue is within a tolerance level of our expected RPM, the register offset is storedfor later use. Once all registers have been checked, the attack continues as inattack 1 for each of the target registers found. The modbuster side of the attackis shown in figure 8; the behavior of modbussim is similar to that depicted infigure 7, but with 100 registers and a randomly selected RPM register.

3.5 Attack 3

The third challenge was to ‘blow up’ modbussim assuming the attacker knows (i)the IP address of the simulated PLC, but nothing else. Note that not knowingthe port is logically equivalent to not knowing the IP address and port.

modbuster accomplishes this by port scanning for valid Modbus connec-tions.10 If a connection is successful then registers are read until a valid registerrange is found, as in attack 2. If no register is found within the range, thenthe port scan continues at the next port. Note that exception code correctnesstests could also be used for verifying that we have connected to a PLC. How-ever, for the purposes of this attack, that step is superfluous, as we only careabout PLCs connected to the targeted centrifuge. Once a target PLC is found,along with its list of target registers, the attack continues as in attack 1 for eachtargeted register. The modbuster side of the attack is shown in figure 9; again,the behavior of modbussim is similar to that depicted in figure 7, but with 100registers, a randomly selected RPM register, and a randomly selected port.

10Nmap was considered, but we found it does not support the specific features needed forthis attack.

10

Figure 9: modbuster successfully discovers a Modbus port, determines whichregisters to attack, and then performs response injection until the centrifugeexplodes.

3.6 Attack 4

The final attack we investigated is a pure reconnaissance attack. As suggestedby the preceding experiments, executing a response injection attack requiresdetermining which ports and registers should be targeted. Generalizing, a firststep in any exploit is simply figuring out what different PLCs on a networkare doing; indeed, in some contexts (e.g., stealing trade secrets), an attackermight prefer to exclusively gather data rather than tamper with the behaviorof an industrial system. So, in this experiment we investigate the potentialfor performing a man-in-the-middle attack via ARP poisoning, the goal beingto route Modbus traffic through the attacker’s machine, where it can then beanalyzed.

For this experiment, we ran an instance of modbussim with 10 registers onone Raspberry Pi, and on the second ran a monitoring tool (modbusreader)that queries the PLC registers once every five seconds. This generates Modbustraffic over the network. The attack machine is an Asus Eee netbook runningXubuntu Linux, and we assume the attacker already has access to the network.To execute ARP poisoning, we use the well-known MitM tool Ettercap [6]. Tofilter Modbus traffic and extract register data, we built a custom Bro networksecurity monitor [3] script. This script extracts and logs register data in packetssent by the PLC in response to a ‘read holding registers’ function request; otherModbus messages are ignored.

The entire attack is remarkably straightfoward. Figure 10 shows the Etter-cap command used to run the attack, as well as the initial output. As can beseen, the attack is successful, and TCP traffic between the PLC and controlleris being logged. Figure 11 shows the output of the Bro script; PLC registerdata is extracted in real time from rerouted Modbus over TCP messages. Fi-nally, since the ultimate goal of the attack is to determine the function of theregisters of PLCs on the network, in figure 12 we plot the extracted data for asubset of registers over time. The plot clearly shows register three is responsible

11

Figure 10: The Ettercap command used to execute ARP poisoning, along withinitial output indicating that traffic has successfully been rerouted. This outputhas been edited for space.

Figure 11: Sample output of the Bro script; PLC register data is extracted inreal time from rerouted Modbus over TCP messages.

12

Figure 12: Register data for a subset of registers over time, as extracted by ourMitM attack. The large jumps in values for registers 1 and 2 are due to rollover.

for maintaining the steady RPMs of the centrifuge. However, the more generalpoint is that the data is successfully acquired and hence can be analyzed usingwhatever tools are suited to the task.

4 Conclusion and Future Work

In this paper, we (i) described our Modbus PLC simulation, modbussim; (ii)presented a unified tool – modbuster – for performing pure response injectionand combined reconnaissance and response injection attacks; and (iii) provideda successful demonstration of an ARP man-in-the-middle pure reconnaissanceattack for gathering PLC register data transmitted using Modbus over TCP.

This research suggests many possible avenues for future work. For instance,one might attempt to extend the MitM attack to include response injectionby modifying Modbus read requests so that PLC responses do not indicate tothe master controller that anything is awry with the connected machinery; inthat case, modbuster could be executed covertly. Second, modbussim coversonly a small fraction of what goes on in an actual PLC, so there are manyopportunities for expanding the capacities of the simulator. Third, modbustercould be expanded to more effectively hide its activity on the network. Finally,there are libraries implementing other common SCADA protocols, e.g. DNP3.11

11E.g., https://sourceforge.net/projects/dnp/ and https://github.com/automatak/dnp3

13

It would be interesting to explore the potential for similar attacks for theseprotocols.

References

[1] Nidhal Ben Aloui. “Industrial Control Systems Dynamic Code Injection”.In: GreHack. 2015.

[2] Dillon Beresford. “Exploiting Siemens Simatic S7 PLCs”. In: Black HatUSA 2011. Las Vegas, NV, July 2011.

[3] Bro Network Security Monitor. url: https://www.bro.org/.

[4] Dong Jin, David M. Nicol, and Guanhua Yan. “An event buffer floodingattack in DNP3 controlled SCADA systems”. In: Proceedings of the 2011Winter Simulation Conference (WSC). IEEE, Dec. 2011, pp. 2614–2626.isbn: 978-1-4577-2109-0 978-1-4577-2108-3 978-1-4577-2106-9 978-1-4577-2107-6. doi: 10.1109/WSC.2011.6147969.

[5] Samuel East et al. “A Taxonomy of Attacks on the DNP3 Protocol”. en. In:Critical Infrastructure Protection III. Ed. by Charles Palmer and SujeetShenoi. IFIP Advances in Information and Communication Technology311. DOI: 10.1007/978-3-642-04798-5 5. Springer Berlin Heidelberg, Mar.2009, pp. 67–81. isbn: 978-3-642-04797-8 978-3-642-04798-5. url: http://link.springer.com.libproxy.unm.edu/chapter/10.1007/978-3-

642-04798-5_5.

[6] Ettercap. url: https://ettercap.github.io/ettercap/.

[7] libmodbus. url: http://libmodbus.org/.

[8] Malaz Mallouhi et al. “A testbed for analyzing security of SCADA controlsystems (TASSCS)”. In: IEEE, Jan. 2011, pp. 1–7. isbn: 978-1-61284-218-9. doi: 10.1109/ISGT.2011.5759169. url: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5759169.

[9] Modbus Messaging on TCP/IP Implementation Guide. url: http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.

pdf.

[10] Modbus Application Protocol V1 1b3. url: http://www.modbus.org/

docs/Modbus_Application_Protocol_V1_1b3.pdf.

[11] Thomas H. Morris and Wei Gao. “Industrial Control System Cyber At-tacks”. In: BCS, Sept. 2013, pp. 22–29. isbn: 978-1-78017-232-3. url:http://dl.acm.org/citation.cfm?id=2735338.2735341.

[12] pymodbus. url: https://pypi.python.org/pypi/pymodbus3/1.0.0.

14