Electronics | Free Full-Text | Industrial Control Systems Security Validation Based on MITRE Adversarial Tactics, Techniques, and Common Knowledge Framework
1. Introduction
1.1. Motivation
In summary, the motivation for this paper is twofold: firstly, to address the pressing need for practical security validation in the face of evolving cyber threats targeting ICSs; and secondly, to deepen the understanding of ICS-specific security challenges and contribute to the development of effective security strategies.
1.2. Problem Statement
Despite the advancement of security in the ICS domain, systems have become increasingly interconnected, IT systems are also being integrated with Operation Technology (OT) systems, the environments have become more complex, and the risk of cyber threats has significantly grown. A single effective breach in this environment could result in severe repercussions, disrupt vital services, inflict economic harm, and potentially cause physical harm to individuals or equipment. However, with the implementation of effective security, IOC monitoring, and validation, these systems can be controlled effectively.
Some open-source tools, such as Suricata, Snort, Wazuh, and Wireshark, provide security monitoring and validation of DoS attacks and ARP poisoning Man-in-the-Middle (MITM) attacks in the ICSs environment. In this paper, the main problem that is addressed is validating IOCs in an ICS attack scenario using open-source tools.
1.3. Our Contribution
In response to the escalating challenges posed by the increasing interconnectivity of ICS and the integration of IT with OT, this paper addresses the importance of security validation within this environment. A successful breach in this intricate ecosystem could lead to severe repercussions, including the disruption of vital services. In this context, our paper focuses on the implementation of effective security measures, IOC monitoring, and validation to enhance the resilience of ICS environments. We recognise that the integration of IT systems with OT systems has introduced new vulnerabilities, making it imperative to devise robust strategies for safeguarding against cyber threats. While open-source tools such as Suricata, Snort, Wazuh, and Wireshark have proven effective in monitoring and validating DoS attacks and ARP poisoning attacks in ICSs, our paper addresses the crucial importance of validating IOCs in the event of an ICSs attack scenario. By focusing on IOCs, we aim to contribute insights that:
-
Empower organisations to effectively detect and respond to potential security incidents in their ICS infrastructure.
-
Emphasise the importance of leveraging open-source tools for IOC validation, thereby enabling organisations to strengthen their defence mechanisms against evolving cyber threats in ICSs at a reduced cost.
-
Through practical implementations and empirical evaluations, provide valuable contributions to the field, helping to secure critical infrastructure and mitigate the potential consequences of cyber-attacks in the ICS domain.
2. Background and Related Work
This section presents the fundamental terms used in ICS along with associated research conducted in this domain.
2.1. Related Terminology
2.2. Related Work
2.3. Addressing the Research Gap
3. System Model, Attack Model, and Capabilities
3.1. System Model
The proposed system model integrates a PLC (OpenPLC), a traffic light system as a slave device, and a SCADA system, specifically ScadaBR, to establish a comprehensive and interactive control environment. This model is designed to simulate real-world ICS operations and interactions, with a focus on examining the efficacy of control logic under varying conditions. Each plays a distinct role in the operational simulation, as follows:
Arduino traffic light system (Slave Device). The traffic light system, functioning as a slave device, provides observable outputs based on the control logic executed by the OpenPLC. Its behaviour offers insights into the accuracy and reliability of the control commands issued by the OpenPLC.
3.1.1. Communication and Interaction
Communication between these components is orchestrated using the Modbus protocol. The OpenPLC sends and receives data to and from the traffic light system over Modbus. The ScadaBR system receives the control commands from the OpenPLC and allows the operator to issue these commands, which are then transmitted back to the OpenPLC for execution.
3.1.2. Traffic Light Control Logic
The traffic light system’s response to the control logic provides a practical framework for evaluating the efficacy of the PLC’s command execution and the overall system’s reliability and safety.
-
Timers of flight (TOF0, TOF1, TOF2): these provide delays for transitions between light states.
-
Falling edge triggers: these detect transitions from ON to OFF in light-emitting diodes (LEDs), initiating subsequent light changes.
-
LEDs control logic: incorporates red, orange, and green LEDs, each activated under specific conditions to ensure a smooth transition between light states.
-
Safety and diagnostic features: includes a feature to detect if no lamps are active for over a second, indicating potential malfunctions.
-
Startup and initialisation: a timer at startup (TON0) stabilises the system before LED operations commence.
-
Execution cycle configuration: the PLC’s execution cycle is set to a 20-millisecond interval, ensuring timely responses and continuous condition evaluation.
3.2. Attacker Model and Capabilities
This paper’s examination of attacks is based on specific assumptions that define the attacker model. In this attack model, we assume that the adversary has successfully infiltrated the target environment by employing social engineering techniques. The attacker has acquired unauthorised remote access privileges within the OT network. However, we assume that the attacker’s knowledge of the system model gives them the capacity to perform the following attacks:
These skills will be further detailed and categorised by applying the MITRE ATT&CK framework.
The tools used in these attacks are:
-
Hping3. Hping3 is a versatile network tool used for network scanning, packet crafting, and firewall testing. It enables the customisation and transmission of Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and TCP packets; hence, it is valuable for network diagnostics and security assessments [11].
-
Kali Linux. The Kali operating system (OS) is a renowned penetration testing and ethical hacking distribution equipped with a comprehensive toolkit for security assessments, vulnerability testing, and ethical hacking. It is widely utilised by cybersecurity professionals and researchers [10].
-
Ettercap. Ettercap is a comprehensive suite for MITM attacks on a Local Area Network (LAN). It features sniffing live connections, content filtering on the fly, and many other interesting tricks. It supports an active and passive dissection of many protocols and includes various features for network and host analysis. Typically used for ARP poisoning attacks, Ettercap can intercept data on a network and potentially modify traffic, making it a powerful tool for network security assessments and for understanding network vulnerabilities [24].
-
Wireshark. Wireshark is a prominent network protocol analyser. It can be used to monitor, capture, and analyse Modbus protocol communication, assisting in identifying network anomalies, troubleshooting issues, and enhancing the security and reliability of ICS networks. This makes Wireshark an invaluable asset for maintaining efficient and secure industrial operations [7].
3.3. Description of Attacks
A DoS attack involves an attacker flooding a system or network with excessive traffic or malicious activity to disrupt its normal functioning, causing it to become inaccessible to legitimate users. In an MITM attack, an attacker inserts itself into communication between two devices with the intention of either listening in on the conversation or pretending to be one of the devices, creating the illusion of a legitimate exchange of information.
3.3.1. Attack Scenario I
To execute this attack, the attacker crafts a script command that exploits vulnerabilities in the Modbus protocol, which typically operates on TCP port 502. This script is designed to continuously send a barrage of TCP packets to the PLC’s communication interface. Given that the PLC is expecting Modbus packets on port 502, it will try to process each incoming packet. However, since these packets are maliciously crafted and sent in rapid succession, the PLC becomes overwhelmed, exhausting its computational resources.
The packets sent by the attacker might have randomised source Internet Protocol (IP) addresses, making them challenging to trace back to the actual origin of the attack. This technique, known as IP address spoofing, further complicates the mitigation process. As the PLC struggles to process the flood of incoming packets, its responsiveness to genuine Modbus commands diminishes, leading to significant operational downtime and potentially jeopardising the safety and functionality of the system.
3.3.2. Attack Scenario II
The attack unfolds in stages. It begins with an ARP cache poisoning technique. Here, the attacker leverages tools like Ettercap to poison the ARP cache of both the SCADA system and the PLC. This deceit ensures that both entities mistakenly recognise the attacker’s machine as the legitimate communication partner. Consequently, all Modbus/TCP packets intended for the SCADA system or the PLC are inadvertently channelled through the attacker’s machine.
Having discreetly established this MITM position, the attacker gains an unobstructed view of the Modbus/TCP packets shuttling between the SCADA system and the PLC. As the packets transit through the attacker’s machine, every piece of information, command, and response becomes visible to the attacker, offering an unparalleled insight into the operations and communications between the SCADA and the PLC.
4. Our Approach
Security validation in ICSs is instrumental for comprehending the behaviour of assets and systems under diverse forms of attack as well as empowering proactive responses. Our proposed approach is designed to assist industrial users, including system operators and cybersecurity engineers, in comprehending, identifying, and proactively responding to DoS attacks and ARP poisoning attacks on ICSs within their operational environment, thereby preventing potential damage.
In this work, we utilised open-source tools to showcase the practical application of our approach. The obtained results will equip operators with valuable insights to make informed and proactive decisions, such as to swiftly identify and address potential threats, minimising the risk of damage. Beyond its immediate practical implications, our work will also contribute to the broader academic research landscape in ICS security validation by showcasing the effective utilisation of open-source tools in validating IOCs for specific attack scenarios.
4.1. Experimental Design
-
Windows 10 (64-bit) Virtual Machine (IP: 192.168.56.105): the Windows server is a virtual box and hosts the ScadaBR application, which serves as the HMI for monitoring and controlling the traffic light system.
-
Ubuntu 22.04 virtual server (IP: 192.168.56.107): The Ubuntu machine hosts the OpenPLC-v3, which is responsible for controlling the slave device. Additionally, the snort_v3 IDS and Suricata IDS are also installed on the Ubuntu server for monitoring network traffic for suspicious activities.
-
Debian OS (IP 192.168.56.106): Debian OS is deployed within the network to support additional security and monitoring components. It is dedicated to hosting and configuring the Wazuh SIEM solution.
-
Kali Linux Virtual Machine (IP 192.168.56.102): Since the attacker is assumed to already have access to the ICS environment and have full knowledge of the system model, it is represented as a Kali virtual and has been added to the network. It has been configured with all the necessary tools to aid in launching the attacks on IP 192.168.56.102.
-
We assigned a name to our data source connection as “serl traffic light” and the connection type as “Modbus IP”.
-
Set the update period to “500 ms” for real-time updates.
-
Set the timeout to “500 ms”.
-
Transport type to “TCP with keep-alive”.
-
Host IP address to the OpenPLC runtime IP: “192.168.56.107”.
4.2. Overall Execution
When our attack is simulated from the attacker’s machine, the network IDS (NIDS)’s open-source tool equipped with predefined rules for detecting IOCs will promptly flag and log the identified attack. Subsequently, the logs will be transmitted to our SIEM solution, which, in turn, will process the data, trigger alerts, and visually present the information on a dashboard. This process enables a proactive response by the system operator, ensuring timely awareness and swift actions to mitigate potential threats.
5. Results
5.1. Open-Source Tools
5.1.1. Network Intrusion Detection System
-
Snort. Snort IDS is a widely used open-source IDS. It is designed to actively monitor network traffic for intrusion detection and the prevention of malicious network activities in real time [27]. Utilising its signature engine, continuous community backing, and ongoing development efforts simplifies the deployment of new detection rules.
-
Suricata. Suricata is an open-source Network IDS, IPS, and Network Security Monitoring (NSM) engine. It is known for its capability to provide real-time intrusion detection, which is essential for monitoring and safeguarding network traffic against malicious activities.
5.1.2. SIEM, Dashboard, and Visualisation Utilisation
Wazuh is equipped with pre-configured settings and data parsers for various security tools, including our IDS tools, Snort, and Suricata, to process alerts and logs efficiently. We configured and integrated Snort IDS and Suricata IDS. The alerts and logs from Suricata and Snort are directed to the Wazuh agent and manager for further handling. The Wazuh manager correlates these alerts and system logs with other security events, enforces additional security rules, and triggers custom responses based on the received data. Wazuh plays a crucial role in providing a comprehensive view of the security status of the ICS environment. It also has a dashboard capability, which we leveraged to visually represent security events and alert trends, aiding in quick identification and validation.
5.2. DoS Attack Validation (Attack Scenario I)
5.2.1. Suricata Performance
The detailed explanation of the command “hping3 -d 120 -s -w 64 -p 502 –flood –rand-source –interval u1000 192.168.56.107” is as follows:
-
-d 120: Set the byte size of the data section (payload) of the packet to 120 bytes.
-
-s: Spoof the source address (make it look like the packets are coming from a different IP).
-
-w 64: Set the TCP window size to 64.
-
-p 502: Target port 502.
-
–flood: Send packets as fast as possible without showing any output.
-
–rand-source: Randomise the source IP address.
-
–interval u1000: Send one packet every 1000 microseconds.
-
192.168.56.107: The target IP address.
5.2.2. Wazuh Alert Correlation
5.3. ARP Poisoning Attack Validation (Attack Scenario II)
Network Behaviour Analysis
Substantial anomalies in the network behaviour were identified and logged by our Snort IDS tools and the Wazuh SIEM solution. These indicators of the various stages of the ARP poisoning attack validate the effectiveness of the techniques and tools employed in identifying the security breach.
6. Conclusions
The work described in this paper has explored the area of cyber-attack validation in ICSs. We have validated two common attacks, DoS and ARP poisoning attacks, in ICSs.
The techniques deployed successfully addressed the attacks mentioned in the threat model. The accurate detection and timely validation of the DoS and ARP poisoning attacks indicate a high level of security efficacy. In terms of performance, the implementation of security measures showed a high degree of reliability. The tools used were able to validate the mapped IOCs of the ICS environment under test. The alignment with the MITRE ATT&CK framework further validates the security measures, confirming that the techniques are not only effective in a simulated environment but also applicable in real-world ICS scenarios. Key findings from the simulated attack scenarios demonstrate the effectiveness of the proposed approach.
The DoS attack validation revealed significant vulnerabilities within the PLC’s Modbus protocol communication, a finding that underscores the importance of robust network traffic monitoring and intrusion detection systems. Similarly, the ARP poisoning attack validation highlighted the critical need for vigilant network behaviour analysis and the importance of regular checks for discrepancies in ARP tables. Therefore, the attack validation scheme proposed in this paper is useful for the future development and security of ICSs. The results not only validate the proposed methods but also provide actionable insights for ICS security enhancements.
However, the constantly evolving landscape of cyber threats, especially with the advent and incorporation of IoT devices, edge computing, and cloud services in ICSs, necessitates a broader exploration of potential threat avenues. Future work includes simulating and validating more attacks, such as malware attacks and supply chain attacks.
Author Contributions
Conceptualisation, D.S.A. and M.A.; methodology, D.S.A., M.A. and N.S.; writing—original draft preparation, D.S.A.; writing—review and editing N.S.; supervision, N.S. All authors have read and agreed to the published version of the manuscript.
Funding
This research received no external funding.
Data Availability Statement
Data is contained within the article.
Conflicts of Interest
The authors declare no conflicts of interest.
References
- Asiri, M.; Saxena, N.; Gjomemo, R.; Burnap, P. Understanding Indicators of Compromise against Cyber-attacks in Industrial Control Systems: A Security Perspective. ACM Trans. Cyber-Phys. Syst. 2023, 7, 1–33. [Google Scholar] [CrossRef]
- Security Affairs. (14 March 2022). Anonymous Hacked German Subsidiary Rosneft. Security Affairs. Available online: https://securityaffairs.co/129052/hacktivism/anonymous-hacked-german-subsidiary-rosneft.html (accessed on 13 February 2024).
- Railway Technology. Belarus: Hackers Attack Train Systems. 29 December 2023. Available online: https://www.railway-technology.com/news/belarus-hackers-attack-train-systems/ (accessed on 13 February 2024).
- Huang, H.; Zhang, N.; Luo, X.; Xu, Y.; Xu, Z. A Survey on Threat Intelligence-driven Industrial Control System Security. IEEE Trans. Ind. Inform. 2021, 1–20. [Google Scholar]
- Ahmadi-Assalemi, G.; Al-Khateeb, H.M.; Epiphaniou, G.; Aggoun, A. Super Learner Ensemble for Anomaly Detection and Cyber-Risk Quantification in Industrial Control Systems. IEEE Internet Things J. 2022, 9, 13279–13297. [Google Scholar] [CrossRef]
- Mohammed, A.S.; Anthi, E.; Rana, O.; Saxena, N.; Burnap, P. Detection and mitigation of field flooding attacks on oil and gas critical infrastructure communication. Comput. Secur. 2023, 124, 103007. [Google Scholar] [CrossRef]
- Melamed, R.; Shabtai, A.; Elovici, Y. Adversarial Attacks on Industrial Control Systems: A Survey on Techniques and Mitigation Approaches. IEEE Trans. Ind. Inform. 2021, 17, 5719–5736. [Google Scholar]
- Clarke, S. SCADA: Supervisory Control and Data Acquisition; ISA: Tokyo, Japan, 2013. [Google Scholar]
- Stouffer, K. Cybersecurity in SCADA. Cybersecur. Ind. Syst. 2018, 6, 22–29. [Google Scholar]
- Thompson, R. Centralized monitoring in SCADA systems. IEEE Ind. Electron. Mag. 2016, 10, 28–37. [Google Scholar]
- Hughes, T. Data acquisition in SCADA. Autom. Constr. 2018, 22, 405–412. [Google Scholar]
- Kumar, A. Alarm management in SCADA. Process Control J. 2019, 12, 44–50. [Google Scholar]
- Choi, S.; Choi, J.; Yun, J.-H.; Min, B.-G.; Kim, H. Expansion of ICS Testbed for Security Validation based on MITRE ATT&CK Techniques. In Proceedings of the 13th USENIX Workshop on Cyber Security Experimentation and Test, Online, 10 August 2020. [Google Scholar]
- Fernandez, G. SCADA and modern tech. Ind. Inform. J. 2021, 18, 39–46. [Google Scholar]
- Gomez, J. SCADA’s efficiency role. Ind. Inform. Rev. 2020, 16, 58–65. [Google Scholar]
- Gharibi, R.H.; Zarei, A.M.; Khayyambashi, M.R. A Review on Security Validation Techniques for Industrial Control Systems. In Proceedings of the 2019 IEEE International Conference on Industrial Cyber-Physical Systems (ICPS), Taipei, Taiwan, 6–9 May 2019. [Google Scholar]
- Banik, S.; Banik, T.; Hossain SM, M.; Saha, S.K. Implementing Man-in-the-Middle Attack to Investigate Network Vulnerabilities in Smart Grid Test-bed. In Proceedings of the 2023 IEEE World AI IoT Congress (AIIoT), Seattle, WA, USA, 7–10 June 2023. [Google Scholar]
- Chen, B.; Butler-Purry, K.L.; Goulart, A.; Kundur, D. Implementing a Real Cyber-Physical System Test Bed in RTDS and OPNET. In Proceedings of the 2014 North American Power Symposium (NAPS), Pullman, WA, USA, 7–9 September 2014; pp. 1–6. [Google Scholar]
- Yılmaz, E.N.; Ciylan, B.; Gönen, S.; Sindiren, E.; Karacayılmaz, G. Cyber Security in Industrial Control Systems: Analysis of DoS Attacks against PLCs and the Insider Effect. In Proceedings of the 2018 6th International Istanbul Smart Grids and Cities Congress and Fair (ICSG), Istanbul, Turkey, 25–26 April 2018. [Google Scholar]
- Dragon, Inc. Mapping-Industrial-Cybersecurity-Threats-to-MITRE-ATTACK-for-ICS. Scribd. April 2020. Available online: https://www.scribd.com/document/505064681/Mapping-Industrial-Cybersecurity-Threats-to-MITRE-ATTACK-for-ICS (accessed on 25 February 2024).
- Bhatia, S.; Kush, N.; Djamaludin, C.; Akande, J.; Foo, E. Practical Modbus Flooding Attack and Detection; Information Security Discipline, Queensland University of Technology: Queensland, Australia, 2019. [Google Scholar]
- Dehlaghi-Ghadim, A.; Balador, A.; Moghadam, M.H.; Hansson, H.; Conti, M. ICSSIM—A framework for building industrial control systems security testbeds. Comput. Ind. 2023, 148, 103906. [Google Scholar] [CrossRef]
- Rahman, A.; Mustafa, G.; Khan, A.Q.; Abid, M.; Durad, M. Comprehensive Analysis of Vulnerabilities in the Modbus Protocol and Exploitation through Denial of Service Attacks. Int. J. Crit. Infrastruct. Prot. 2022. [Google Scholar]
- Haitao, X.; Chen, Z.; Song, L.; Bo-Sian, J.; Zhigang, L.; Fei, W.; Yuling, L. CapsITD: Malicious Insider Threat Detection Based on Capsule Neural Network. In Proceedings of the International Conference on Security and Privacy in Communication Systems, Hongkong, China, 19–21 October 2023. [Google Scholar] [CrossRef]
- Rajesh, L.; Satyanarayana, P. Detecting Flooding Attacks in Communication Protocol of Industrial Control Systems. Int. J. Adv. Comput. Sci. Appl. 2020, 11, 396–400. [Google Scholar]
- Sahu, A.; Mao, Z.; Wlazlo, P.; Huang, H. Multi-Source Multi-Domain Data Fusion for Cyberattack Detection in Power Systems. IEEE Access 2021, 9, 2–20. [Google Scholar] [CrossRef]
- Roesch, M. Snort: Lightweight Intrusion Detection for Networks. In Proceedings of the Large Installation System Administration Conference (LISA), Seattle, WA, USA, 7–12 November 1999; Volume 99, pp. 229–238. [Google Scholar]
Figure 1.
ICS architecture.
Figure 1.
ICS architecture.
Figure 2.
Attack model.
Figure 3.
Experimental ScadaBR configuration.
Figure 3.
Experimental ScadaBR configuration.
Figure 4.
Experimental hardware equipment with connections.
Figure 4.
Experimental hardware equipment with connections.
Figure 5.
State changes in the OpenPLC logs before and after the DoS attack. (a) Pre-DoS attack; (b) post-DoS attack.
Figure 5.
State changes in the OpenPLC logs before and after the DoS attack. (a) Pre-DoS attack; (b) post-DoS attack.
Figure 6.
ScadaBR connection during a DoS attack.
Figure 6.
ScadaBR connection during a DoS attack.
Figure 7.
Wireshark captures traffic during a DoS attack.
Figure 7.
Wireshark captures traffic during a DoS attack.
Figure 8.
Suricata DoS alert logs.
Figure 8.
Suricata DoS alert logs.
Figure 9.
DoS attack alerts on the Wazuh dashboard. (a) DoS attack alert; (b) DoS attack alert group.
Figure 9.
DoS attack alerts on the Wazuh dashboard. (a) DoS attack alert; (b) DoS attack alert group.
Figure 10.
ARP tables.
Figure 11.
Snort ARP alert logs.
Figure 11.
Snort ARP alert logs.
Table 1.
Literature review and related work.
Table 1.
Literature review and related work.
Author(s) | Focus Area | Key Contribution | Limitations | Alignment with Research Scope |
---|---|---|---|---|
[6] | Modbus TCP vulnerabilities | Highlighted susceptibility to cyberattacks | Focus on simulated environments; questions real-world applicability | Addresses risks in interconnected ICSs |
[13] | Enhancement of ICSs testbeds | Development of ICS datasets for security analysis | Limited by existing frameworks of testbeds and datasets | Supports the need for empirical research |
[17] | Testbed validation with MITM attack | Demonstrated effectiveness of testbed through MITM attack | Not provided | Validates testbed under real-world attack scenarios |
[18] | Real-time cyber-physical testbed | Conducted MITM and DoS attacks to validate testbed effectiveness | Not provided | Validates testbed in real-world scenarios |
[19] | DoS attacks on PLCs | Analysed impact of DoS attacks; importance of availability in ICSs | Limited in addressing comprehensive vulnerabilities | Relates to simulating attack scenarios |
[20] | Threat behaviours in ICSs | Shift from anomaly detection to behaviour-based analysis | Focuses mainly on network anomalies | Aligns with exploring ICSs-specific IOCs |
[21] | Modbus flooding attacks | Effectiveness of anomaly-based detection algorithms | Does not address the broader spectrum of ICS vulnerabilities | Echoes dynamic nature of ICS threats |
[22] | Testbed for ICS security validation | Development of ICS dataset validation tool | Limited by existing frameworks of testbeds and datasets | Relates to the simulation of large-scale scenarios |
[23] | Mitigation strategies (Modbus) | Integration of security measures across OSI model layers | Highlights lack of comprehensive strategies for Modbus security | Points to the need for holistic security approaches |
Table 2.
Arduino traffic light system diagram settings.
Table 2.
Arduino traffic light system diagram settings.
Point Name | Type | Location | Status | Value |
---|---|---|---|---|
RED_Light | Boolean | %Q×100.0 | ON | True |
YELLOW_Light | Boolean | %Q×100.1 | ON | True |
GREEN_Light | Boolean | %Q×100.2 | OFF | False |
Table 3.
DoS attack indicators.
Table 3.
DoS attack indicators.
Indicator | MITRE ATT&CK Tactic | MITRE ATT&CK Technique | Description |
---|---|---|---|
High volume of incoming network packets to the PLC on port 502 | Impact | Network Denial of Service (T1498) | The attacker is sending an overwhelming number of packets to the PLC, aiming to exhaust its resources. |
Continuous traffic from randomised source IP addresses | Defence Evasion | Masquerading (T1036) | The attacker employs IP address spoofing to obfuscate their true origin, resulting in traffic from seemingly random IP addresses. |
Unusual or malformed Modbus packets | Initial Access | Exploit Public-Facing Application (T1190) | The attacker crafts and sends malicious packets designed to exploit vulnerabilities in the Modbus protocol. |
Anomalies in PLC behaviour or control decisions | Impact | Impact on Business. Service stop (T1489) | The PLC might make unexpected control decisions or fail to process genuine commands due to the flood of packets. |
Table 4.
DoS attacks’ IOCs.
Table 4.
DoS attacks’ IOCs.
IOCs | Recommended Measures | Security Components | Validation Tool(s) |
---|---|---|---|
High volume of incoming network packets to the PLC on port 502 | Implement continuous network traffic monitoring and analysis to identify unusual patterns. Implement rate limiting for incoming Modbus requests. | Intrusion Detection Systems (IDS) | Suricata and Wireshark |
Continuous traffic from randomised source IP addresses | Continuously monitor network traffic for patterns indicating IP address spoofing. Employ ingress and egress filtering to block traffic with spoofed or suspicious source IP addresses. | Network Monitoring Tools, Firewalls | Wazuh security information and event management (SIEM), Suricata |
Deep packet inspection, signature-based detection | Deploy deep packet inspection to analyse Modbus traffic. Use signature-based detection to identify malicious Modbus packets. | IDS | Suricata, Wireshark |
Anomalies in PLC behaviour or control decisions | Implement SIEM solution for centralised event management. Configure rules and alerts for security incidents. Correlate events from multiple systems for threat detection. | Anomaly Detection Systems | Wazuh SIEM, PLC Logs |
Table 5.
ARP poisoning attack indicators.
Table 5.
ARP poisoning attack indicators.
Indicator | MITRE ATT&CK Tactic | MITRE ATT&CK Technique | Description |
---|---|---|---|
ARP Traffic Anomalies | Discovery | Network Service Scanning (T1046) | A surge in ARP traffic indicates attempts to identify devices on the network by sending ARP requests. |
Media Access Control (MAC) Address Discrepancies in ARP tables | Defence Evasion | Spoofing (T1564) | Manipulated ARP tables show the attacker’s MAC address associated with a legitimate IP. |
Modbus/TCP Traffic Irregularities | Collection | Network Traffic Capture (T1042) | Intercepted or altered Modbus/TCP packets lead to unexpected network traffic patterns. |
Presence of ARP Spoofing Tools | Discovery | System Network Configuration Discovery (T1016) | Tools like Ettercap on the network signify ARP cache poisoning attempts. |
Table 6.
ARP poisoning attacks’ IOCs.
Table 6.
ARP poisoning attacks’ IOCs.
IOCs | Recommended Measures | Security Components | Validation Tool(s) |
---|---|---|---|
ARP Traffic Anomalies | Implement continuous network traffic monitoring and analysis. | IDS | Snort/Wireshark |
Deep Packet Inspection, Signature-Based Detection | Deploy deep packet inspection to analyse packet payloads. Use signature-based detection for known attack patterns. | IDS | Snort |
MAC Address Discrepancies in ARP Tables | Continuously monitor ARP tables for discrepancies. Validate MAC address associations with IP addresses. | Network Monitoring Tools | Arptables |
Modbus/TCP Traffic Irregularities | Implement deep packet inspection for Modbus traffic. Analyse Modbus packet anomalies. | IDS | tcpdump, Wireshark, Snort |
ARP Spoofing Detection | Deploy intrusion detection systems that can detect ARP spoofing attempts. Regularly scan for the presence of ARP spoofing tools. | IDS | Snort |
Table 7.
Experimental equipment configuration.
Table 7.
Experimental equipment configuration.
Equipment/Component | System/Software/Version | IP Address |
---|---|---|
Windows 10vm | Windows 10 (64-bit), Base Memory: 2048 MB. | 192.168.56.105 |
ICS Project | Ubuntu (64-bit), Base Memory: 2096 MB, Processors: 2 | 192.168.56.107 |
Kali-linux-2022.4-virtualbox-amd64 | Kali-Linux-2022.4-virtualbox-amd64 Memory: 2048 Processors: 2 |
192.168.56.102 |
Wazuh v4.5.1 Ova | Wazuh v4.5.1 Ova, Linux 2.6 /3.x/4.x (64-bit), Base Memory; 2313 MB, Processors: 2 | 192.168.56.106 |
Suricata | 7.1 | 192.168.56.107 |
Snort | Snort3 | 192.168.56.107 |
Wazuh | 4.5.1 | 192.168.56.106 |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |