A method for collecting evidence of control logic attacks on industrial controllers

Abstract

This invention discloses a method for collecting evidence from control logic attacks on industrial controllers. The method primarily involves extracting PLC binary control application files by simulating the PLC's upload function; performing reverse engineering on the extracted binary files, including identifying the PLC binary's assembly instruction set architecture, performing disassembly analysis, identifying the PLC programming language, and generating an assembly log file; and performing attack detection, attack location, attack analysis, and attack recovery based on the generated assembly log file. This method effectively collects evidence from control logic attacks on industrial controllers without requiring PLC source code, plant behavior models, or any network traffic. The method can automatically execute the entire process within acceptable time and memory overhead.

Description

Technical Field

[0001] The present invention belongs to the field of industrial control system security and relates to a method for collecting evidence of control logic attacks on industrial controllers. Background Art

[0002] Industrial control systems (ICS) provide control and monitoring capabilities for industrial production processes and play a key role in critical infrastructure industries such as natural gas, electricity, water treatment, chemicals, pharmaceuticals, and food. However, cyberattacks on these critical systems would have widespread and significant impacts on society. In particular, programmable logic controllers (PLCs) are vulnerable to control logic attacks. Attackers can disrupt physical production processes by tampering with the PLC's control logic program. Attackers manipulate the target PLC to perform malicious functions by inserting, deleting, and tampering with the control program's source code or compiled binary control application files. These control logic attacks compromise the integrity of the binary control logic program in the PLC. Summary of the Invention

[0003] This paper proposes a method for efficiently collecting evidence of control logic attacks on industrial controllers, without requiring PLC source code, plant behavior models, or any network traffic. This method uses application-level instruction comparison to locate tampered instructions within PLC control applications and perform subsequent event response actions. Control logic attacks compromise the integrity of binary control applications and modify specific functions and their assembly instructions. Therefore, control logic attacks can be detected by verifying the PLC runtime control application and locating the attack by comparing assembly instructions within different functions.

[0004] The object of the present invention is achieved through the following technical solution: a method for collecting evidence of control logic attacks on industrial controllers, the method comprising the following steps:

[0005] S1, control logic extraction: extract the PLC binary control application file by simulating the PLC upload function;

[0006] S2, reverse analysis of the extracted binary file, including identification of the assembly instruction set architecture of the PLC binary file, disassembly analysis, identification of the PLC programming language, and generation of assembly log files;

[0007] S3, based on the generated assembly log file, performs attack detection, attack location, attack analysis and attack recovery. Specifically, it first detects control logic attacks by calculating the hash value of the extracted control application file and verifying its integrity. Then, it locates the tampered operators and assembly instructions in the control logic and evaluates the impact of the attack on the physical process. Finally, after locating the tampered control application, it writes the original control application into the PLC and restores normal operation.

[0008] Furthermore, the S1 includes the following sub-steps:

[0009] S101, capturing upload function traffic: performing n upload operations using the programming software provided with the industrial controller, and capturing traffic including upload function data packets;

[0010] S102, traffic analysis: According to the program development logic, n upload operations performed by the programming software will generate n upload function data packets. Based on this statistical feature, the traffic is filtered out with n repeated data packet sequences in the same order;

[0011] S103, traffic verification: establish communication with the industrial controller and replay the data packet sequence filtered out in S102 to verify whether it is an upload function data packet;

[0012] S104, upload control application script development: developing a corresponding script program to simulate the upload operation and store the uploaded binary control application;

[0013] S105, binary file extraction: The programming software compiles the source program into binary machine code during the compilation process; in order to extract the runtime binary file in the PLC, when executing the uploaded control application script, the binary control application is extracted from the response message, including the PLC control program, variable data and configuration data.

[0014] Furthermore, the step S2 includes the following sub-steps:

[0015] S201, identifying the assembly instruction set of the proprietary PLC binary file; determining the assembly architecture of the binary file using the machine code corresponding to the assembly instruction;

[0016] S202, disassembling and analyzing the binary file; disassembling the machine code of the binary file into assembly instructions using a disassembly tool, and establishing a function based on the function prologue characteristics of the assembly instruction set;

[0017] S203: Identify different PLC programming languages at the assembly level. For function module diagram languages, each function module has defined required inputs, fixed operation logic, and outputs. By analyzing the assembly instruction composition of different function modules, a correspondence between function modules and assembly instructions is established, and a programming language function module feature library is constructed, thereby completing the identification of function module diagrams and function modules.

[0018] S204, generating an assembly log file; based on the analysis results of the first two steps, recording the assembly instruction, assembly instruction address, function start address, and function end address into the assembly log file.

[0019] Furthermore, the S3 includes the following sub-steps:

[0020] S301, Attack Detection: After the engineer performs the configuration and download operations, the control application is backed up and its hash value is calculated as the original hash value. During the detection phase, the integrity of the control application is regularly verified. First, an upload operation is performed to extract the PLC control application file. Then, the hash value of the extracted control application file is calculated. Finally, the calculated hash value is compared with the original hash value. If the hash values do not match, it indicates that the control application has been tampered with.

[0021] S302, sample file analysis: when it is detected that the control application has been tampered with, the sample control application and the backup control application are analyzed according to step S2 and an assembly log file is generated;

[0022] S303, attack location: Determine the type of control logic attack by comparing the number of assembly instructions in each function in the assembly log file; specifically:

[0023] If the number of assembly instructions for each function remains unchanged, it is considered that the attacker may have tampered with the operators in the control application. Each assembly instruction in the assembly log file is compared in turn to locate the tampered operator.

[0024] If the number of assembly instructions in each function is different from that in the original file, it indicates that the attacker has inserted malicious instructions or deleted normal instructions. The tampered assembly instructions will then be located.

[0025] S304, attack analysis: The programming language has been identified in S203. If it is identified as a functional module graph language, the programming language functional module feature library and the attack location result in S303 are combined to determine which functional module has been tampered with by the attacker;

[0026] S305, logging: recording the tampered operators and assembly instructions to a log file as forensic evidence; evaluating the impact of the attack on the physical processes related to the tampered control application based on the forensic evidence;

[0027] S306, post-disaster recovery: Replace the tampered control application with the original normal control application by using the developed downloader script

[0028] The present invention provides the following advantages: It locates tampered instructions in PLC control applications through application-level instruction comparison and executes subsequent event response actions. Control logic attacks compromise the integrity of binary control applications and modify specific functions and their assembly instructions. Therefore, control logic attacks are detected by verifying the PLC runtime control application and locating the attack by comparing the assembly instructions within different functions. This method effectively collects evidence of control logic attacks in industrial controllers without requiring PLC source code, plant behavior models, or any network traffic. The method can automatically execute the entire process within acceptable time and memory overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a diagram of a method architecture provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0030] The following is a clear and complete description of the technical solutions in the embodiments of the present invention, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0031] This paper proposes a method for collecting evidence of control logic attacks on industrial controllers to effectively collect evidence of control logic attacks without requiring PLC source code, factory behavior models, or any network traffic. Taking the attack evidence collection on Schneider M340PLC as an example, Figure 1 As shown, it mainly includes the following steps:

[0032] S1: Develop a Schneider M340 PLC protocol communication client to simulate the Schneider M340 PLC upload function and extract the Schneider M340 PLC binary control application file based on this. This includes the following sub-steps:

[0033] S101, capturing upload function traffic: PLC programming software usually supports the function of uploading control application programs, allowing the control application programs to be read from the PLC. Therefore, first, n upload operations are performed using the programming software supporting the industrial controller, and the traffic containing the upload function data packets is captured;

[0034] S102, traffic analysis: According to the program development logic, if the programming software performs n upload operations, it will inevitably generate n upload function data packets. Based on this statistical feature, the traffic is filtered out with n repeated data packet sequences in the same order;

[0035] S103, traffic verification: establish communication with the industrial controller and replay the data packet sequence filtered out in S102 to verify whether it is an upload function data packet.

[0036] S104, upload control application script development: developing a corresponding script program to simulate the upload operation and store the uploaded binary control application;

[0037] S105, binary file extraction: During the compilation process, the programming software compiles the source program (such as ladder logic) into binary machine code; in order to extract the runtime binary file in the PLC, when executing the uploaded control application script, the binary control application is extracted from the response message, including the PLC control program, variable data, and configuration data.

[0038] S2, automatically reverse-engineering the extracted PLC binary file; specifically, it includes the following sub-steps:

[0039] S201, identifying the assembly instruction set of the proprietary PLC binary file; because PLC binary files from different manufacturers may use different assembly instruction sets, and different assembly instruction sets vary greatly, the judgment here is mainly based on the machine code corresponding to the assembly instruction;

[0040] Specifically, the machine code and function start assembly instructions of the x86 assembly architecture can be expressed as:

[0041]

[0042] Therefore, the machine code sequence 55 8B EC can be used as one of the credentials to determine that the PLC binary file is of x86 assembly architecture;

[0043] S202, disassembling and analyzing the binary file; after determining the assembly architecture of the binary file, it is necessary to use a disassembly tool to disassemble the machine code of the binary file into assembly instructions, and establish a function based on the function prologue characteristics of the assembly instruction set;

[0044] S203, PLC programming language identification; PLC supports programming languages including ST language, ladder diagram, function module diagram and other languages. Each language is quite different, and the corresponding assembly code after disassembly is also quite different, and the difficulty of subsequent analysis is also different. Therefore, it is necessary to identify different PLC programming languages at the assembly level;

[0045] Specifically, the function module diagram uses a graphical form to express functions. Each function module has defined required inputs, fixed operation logic, and outputs, and is structurally similar to a function. To address this feature, we analyze the assembly instruction composition of different function modules to form a correspondence between function modules and assembly instructions, and construct a programming language function module feature library to complete the identification of function module diagrams and function modules.

[0046] S204, generating an assembly log file; based on the analysis results of the first two steps, recording information such as assembly instructions, assembly instruction addresses, function start addresses, and function end addresses into the assembly log file.

[0047] S3, based on the generated compiled log files, performs attack detection, attack location, attack analysis, and attack recovery. This specifically includes the following sub-steps:

[0048] S301, Attack Detection: After the engineer performs the configuration and download operations, the control application is backed up and its hash value is calculated as the original hash value. Specifically, during the detection phase, the integrity of the control application is regularly verified. First, an upload operation is performed to extract the PLC control application file. Then, a hash value of the extracted control application file is calculated. Finally, the calculated hash value is compared with the original hash value. If the hash values do not match, it indicates that the control application has been tampered with.

[0049] S302, sample file analysis: when it is detected that the control application has been tampered with, the sample control application and the backup control application are analyzed according to step S2 and an assembly log file is generated;

[0050] S303, attack location: determine the type of control logic attack by the change in the number of assembly instructions of each function in the assembly log file;

[0051] Specifically, if the number of assembly instructions for each function remains unchanged, it is considered that the attacker may have tampered with the operators in the control application; therefore, each assembly instruction in the assembly log file is compared in turn to locate the tampered operator;

[0052] If the number of assembly instructions in each function is different from that in the original file, it indicates that the attacker has inserted malicious instructions or deleted normal instructions. The tampered assembly instructions will then be located.

[0053] S304, Attack Analysis: The programming language has been identified in S203. If it is identified as a functional module graph language, based on the programming language functional module feature library and combined with the attack location results in S303, namely the tampered operators, assembly instructions and addresses, it can be determined which specific functional module has been tampered with by the attacker;

[0054] S305, logging: Recording the tampered operators, assembly instructions, and functional modules into a log file as forensic evidence. Finally, based on the forensic evidence, assessing the impact of the attack on the physical processes associated with the tampered control application.

[0055] S306, post-disaster recovery: Recovery will be performed after locating the tampered location and finding out the impact on the physical process. By using the developed downloader script, the tampered control application is replaced with the original normal control application.

[0056] Experimental results demonstrate that this method is highly effective in detecting control logic attacks on Schneider M340 and M580 PLCs, locating tampered control application functions with 100% accuracy. The method can automatically execute the entire process within acceptable time (less than 3.340 seconds per detection cycle) and memory usage (less than 1MB per hour).

[0057] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A method for collecting evidence of control logic attacks on industrial controllers, characterized in that: The following steps are involved: S1, control logic extraction: extract the PLC binary control application file by simulating the PLC upload function; S2, reverse analysis of the extracted binary file, including identification of the assembly instruction set architecture of the PLC binary file, disassembly analysis, identification of the PLC programming language, and generation of assembly log files; S3, based on the generated assembly log file, performs attack detection, attack location, attack analysis, and attack recovery. Specifically, the control logic attack is detected by calculating the hash value of the extracted binary control application file and verifying its integrity. The tampered operators and assembly instructions are then located in the control logic, and the impact of the attack on the physical process is evaluated. Finally, after locating the tampered control application, the original control application is written to the PLC and normal operation is restored. S3 includes the following sub-steps: S301, attack detection: After the engineer performs the configuration and download operations, the control application is backed up and its hash value is calculated as the original hash value; During the detection phase, the integrity of the binary control application file is periodically verified. An upload operation is first performed to extract the PLC binary control application file. A hash value of the extracted binary control application file is then calculated. Finally, the calculated hash value is compared with the original hash value. A mismatch indicates that the control application has been tampered with. S302, sample file analysis: when it is detected that the control application has been tampered with, the sample control application and the backup control application are analyzed according to step S2 and an assembly log file is generated; S303, attack location: Determine the type of control logic attack by comparing the number of assembly instructions in each function in the assembly log file; specifically: If the number of assembly instructions for each function remains unchanged, it is considered that the attacker may have tampered with the operators in the control application. Each assembly instruction in the assembly log file is compared in turn to locate the tampered operator. If the number of assembly instructions in each function is different from that in the original file, it indicates that the attacker has inserted malicious instructions or deleted normal instructions. The tampered assembly instructions will then be located. S304, attack analysis: The programming language has been identified in S2. If it is identified as a functional module graph language, the programming language functional module feature library and the attack location results in S303 are combined to determine which functional module has been tampered with by the attacker; S305, logging: recording the tampered operators and assembly instructions to a log file as forensic evidence; evaluating the impact of the attack on the physical processes related to the tampered control application based on the forensic evidence; S306, post-disaster recovery: by using the developed downloader script, the tampered control application is replaced with the original normal control application.

2. The method for collecting evidence of control logic attacks on industrial controllers according to claim 1 is characterized in that: The S1 includes the following sub-steps: S101, capturing upload function traffic: performing n upload operations using the programming software provided with the industrial controller, and capturing traffic including upload function data packets; S102, traffic analysis: According to the program development logic, n upload operations performed by the programming software will generate n upload function data packets. Based on this statistical feature, the traffic is filtered out with n repeated data packet sequences in the same order; S103, traffic verification: establish communication with the industrial controller and replay the data packet sequence filtered out in S102 to verify whether it is an upload function data packet; S104, upload control application script development: developing a corresponding script program to simulate the upload operation and store the uploaded binary control application; S105, binary file extraction: The programming software compiles the source program into binary machine code during the compilation process; in order to extract the runtime binary file in the PLC, when executing the uploaded control application script, the binary control application file is extracted from the response message, which contains the PLC control program, variable data and configuration data.

3. The method for collecting evidence of control logic attacks on industrial controllers according to claim 1 is characterized in that: The S2 includes the following sub-steps: S201, identifying the assembly instruction set of the proprietary PLC binary file; determining the assembly architecture of the binary file using the machine code corresponding to the assembly instruction; S202, disassembling and analyzing the binary file; disassembling the machine code of the binary file into assembly instructions using a disassembly tool, and establishing a function based on the function prologue characteristics of the assembly instruction set; S203: Identify different PLC programming languages at the assembly level. For function module diagram languages, each function module has defined required inputs, fixed operation logic, and outputs. By analyzing the assembly instruction composition of different function modules, a correspondence between function modules and assembly instructions is established, and a programming language function module feature library is constructed, thereby completing the identification of function module diagrams and function modules. S204, generating an assembly log file; based on the analysis results of the first two steps, recording the assembly instruction, assembly instruction address, function start address, and function end address into the assembly log file.

Images