Penetration testing in industrial IOT environment
Introduction
This report aims to explore and identify vulnerabilities within the network environment through penetration testing techniques. We conducted service discovery, targeted attacks on security risks unique to different devices, employing a variety of technical methods including traffic proxy technology, using jump machines to access the internal network, reverse engineering to analyze device configurations, sniffing network traffic, key cracking, and unauthorized vulnerability exploitation. We documented and analyzed the issues discovered to illustrate the real-world impact of security vulnerabilities in industrial and connected devices. The report was collaboratively completed by our team, with me primarily responsible for the penetration testing portion, while other members contributed to part of the penetration testing and report writing.
Asset Inventory
Environment Setup
The first step to access the IoT devices subnet, is to setup one kalivirtual machine and connect to the access point in 192.168.88.1. Thekali bridge connects to the windows host and manually points to thewireless network interface.
Identifying Active Hosts
Using nmap scan the active host in subnet 192.168.88.0/24 with followingcommand.
1 | |
Figure 1: nmap discovery active host
Figure 1 illustrates the scan results, including some wirelesslyconnected attacker devices (Windows and Kali) within the subnet, whichwill be excluded from following service analysis after checking.
Service Discovery
Based on the host addresses identified in Section 2.2, the next stepinvolves enumerate services running on each host. The [-A]option of nmap is utilized for aggressive scanning, including OSdetection, version detection, traceroute, etc.; the [-sV]option enables service version detection, and [-p-] optionidentifies all available ports. The result for important host is shownin Figure 2, Figure 3, Figure 4.
Figure 2: Scanning result of host 192.168.88.254, which is recognized asthe Philip desk lamp.
Figure 3: Scanning result of host 192.168.88.188, shown as Philips Hue.
In Figure 4, the identified services are totally same for the192.168.88.50 (left) and 192.168.88.189 (right). At the Section 3.2, itshows two Ip addresses is occupied by one machine.
Figure 4: Scanning result of 192.168.88.50 & 192.168.88.189, which lookssimilar that running same services.
The tables below provide a complete inventory of all active devicesidentified on two distinct network segments during the reconnaissancephase. Table 1 summarizes assets discovered on the primary managementsubnet (192.168.88.0/24) via an Nmap ping sweep, listing each host’s IPaddress, open ports, and running services. This baseline inventoryestablishes visibility into core infrastructure components and informssubsequent vulnerability analysis.
Table 1: Active services in subnet 192.168.88.0/24.
Table 2 captures assets on the secondary plant subnet([192.168.2.0/24]), discovered by pivoting through thecompromised host at [192.168.88.186]. It follows the sameformat—IP, MAC/vendor, exposed ports, and service details—to enablea consistent comparison of risk across both network segments and supportprioritized remediation planning.
Table 2: Active services in subnet 192.168.2.0/24
Figure 5: Network and communication structure in System
The above Figure 5 shows the network and communication structure in thewhole system that we analyze. The Simems 2050 is the key device thatconnects to subnet (192.168.88.0/24 and 192.168.2.0/24), which isrunning the Mosquitto broker service, receiving MQTTT messages fromZigbee receiver who collects meter values from sensor. Besides, Simems2050 is also running Node-RED, which collects information from ICSdevices (PLC and HMI) and sensor values. These values will be sent toSCADA Monitor, showing on the panel. Additionally, there are many homessmart devices, which connect to hubs using Zigbee protocol. Users canuse the phone connecting to cloud server on the internet to sendcommands to and get responses from the hubs to control these devices(Light, button and sensor).
The Nmap scan identified port 5000 on host 192.168.88.150 running a webinterface via upnp protocol in Figure 6, enabling direct browser accessto the Smart Plant Monitoring system, revealing connected PLC and HMIdevices and real-time operational status.
Figure 6: Simulate SCADA monitor web page in Ubuntu 192.168.88.150.
Access to port 2050 on 192.168.88.50 requires no credentials shown inFigure 7 — the AV Embedded Configuration interface is exposed andpermits full administrative control without login.
Figure 7: SIEMENS SIMATIC IoT2050 control panel in host192.168.88.50:2050.
In Figure 8, the Node-RED interface on 192.168.88.189:1880 is accessiblewithout authentication and reveals active logic flows for processingsensor data such as temperature, humidity, and conveyor status throughHTTP requests.
Figure 8: Red-node web page in host 192.168.88.189:1880, shows theconnection logic of IoT devices. Which is also available in host192.168.88.50:1880.
Schematic diagram for accessing 192.168.2.10 and viewing the status andconfiguration information of Siemens S7-1200 station_2 | PLC_1 via aweb browser.
Figure 9: Web‑based management interface of the Siemens SIMATIC S7‑1200PLC (CPU 1212C) reachable at [https://192.168.2.10/Portal]
Survey of Plant Monitoring System
Access Point Default Password & Weak Access Control (Main Victim: 192.168.88.1)
An unauthenticated access vulnerability was identified in the RouterOSweb interface at [192.168.88.1], which exposes the fullswitch configuration menu, allowing an attacker to modify core networkinfrastructure without valid credentials, shown in
Figure 10.
Figure 10: Unauthenticated access to the RouterOS web interfaceat [192.168.88.1]
This is a typical misconfiguration issue; leaving critical networkinfrastructure such as access points and routers without passwords orprotected by weak credentials represents a significant security risk.This vulnerability includes multiple threat categories, includingTampering, Repudiation, and Information Disclosure.
Mitigations
This issue can be significantly mitigated through stricter credentialmanagement mechanisms, such as enforcing strong passwords andimplementing multi-factor authentication (MFA). Additionally,controlling access via trusted IP allowlists, maintaining comprehensiveaccess logs, and regularly updating firmware and software are effectivemeasures to reduce risks associated with misconfigurations.
Default Password Pair & Reverse Shell Establishment (Main Victim: 192.168.88.50)
In this section, the attacker remotely ssh connected to the SiemensIoT2050 device ([192.168.88.50]) using default credentialsand executed a trojanized program. Next, a listener was configured onthe Kali machine, along with auto routing and proxy services, therebyestablishing a reverse shell and a proxy server to achieve remote codeexecution (RCE) on the victim machine. Finally, Kali exploitedproxychains to connect through the established proxy, enabling accessto the target network segment (192.168.2.0/24).
Exploitation
The host at [192.168.88.50] (Siemens IoT2050) was identifiedto be using default credentials, allowing SSH connection via the knowndefault password, shown in Figure 11.
Figure 11: Remote connection to Siemens IoT2050 by SSH and defaultusername password pair.
To facilitate pivoting into the secondary network [192.168.2.0/24)], a payload was generated by*[msfvenom]*[1] to establish shell access on the targethost shown in Figure 12. By this step, one reverse shell is obtained forfollowing exploitation.
Figure 12: Payload generation and transfer to remote host(192.168.88.50) by scp command. The upper image used for payloadgeneration, while lower image transfer the payload by scp with anestablished ssh channel.
After the payload subsequently uploaded, and necessary privilegeescalation was performed to gain full access in Figure 13, otherwise thepayload would have no permission to run in victim machine.
Figure 13: Elevation of privilege to payload, allowed payloadrunning in target system.
Then, Metasploit framework (MSF) was used to establish a listener,configure routing, and set up a proxy to facilitate further networkaccess.
Figure 14: The reverse TCP listener configuration involves three primarysteps: 1. initializing the handler with the specified local address andport, 2. configuring autorouting, and 3. finally launching a SOCKS proxyserver.
After successfully obtaining shell access to the host in Figure 15, inFigure 16, utilizing the system command to analyze the networkcommunication in victim, while another network segment was identifiedin.
Figure 15 Launching Metasploit framework and setting up a Reverse TCPListener using an remote control(RC) Script.
Figure 16: Network interface information leaking. The upper imageillustrates the result of [sysinfo] command execution. Andthe secondary subnet [192.168.2.0/24] found in interface 3at lower image.
By configuring a local proxy running at [127.0.0.1:8080]through editing [proxychains.conf] in Figure 17 left image,nmap scans were conducted on this new segment in Figure 17 right image,revealing active hosts: [192.168.2.9],[192.168.2.10], and [192.168.2.130 (found in furtherscanning)].
Figure 17: By fixing the proxy config in[/etc/proxychains.conf] like left image, successfullyexecute nmap command in [192.168.2.0/24] subnet byproxychains.
After connecting to [192.168.88.189] using ssh, it’s easy tosee that [192.168.88.50/24] and[192.168.88.189/24] are both under eno2.
Figure 18: Remote connection to 192.168.88.189. By using command ip a,represents that 192.168.88.50 and 192.168.88.189 is the one machine withdifferent ip address.
Mitigations
Trojan implantation and reverse shell exploitation constitute highlycritical attack vectors. Exploiting RCE vulnerabilities enablesattackers to seize device control, embed hidden backdoors [5], andbotnets [1], among other malicious objectives. Such attacks implicateall six dimensions within the STRIDE threat analysis model.
To mitigate risks highlighted, implementing strong authenticationmethods such as key-based SSH authentication instead of passwords canreduce unauthorized access risks. Proper authorization rules must beenforced to limit user privileges strictly according to their roles.Secondly, unnecessary services and open ports that might disclosesensitive network information should be disabled or hidden to minimizepotential attack surfaces. Additionally, configuring firewall rules toallow only necessary connections and conducting regular software updatescan protect the system from known vulnerabilities, thus significantlyreducing risks of unauthorized access and information disclosure.Moreover, monitoring and alerting suspicious processes and networkconnections through Intrusion Detection Systems (IDS) will also play arole for defense malicious program operation.
Unauthorized RESTful API allows Spoofing of the desk lamp signal (Victim: 192.168.88.188)
Exploitation
A debugger page was accessible athttp://192.168.88.188/debug/clip.html, so 192.168.88.188 wasidentified as an unauthenticated interface capable of controlling thesmart light in the left image of Figure 19. Activating the “Hug” buttonissued a request to the /api endpoint shown in the right image of Figure19, which returned the session token:
mJmYjtqYzB4GpX6LewQ6bN067pnxetiVatbO0lVc
Figure 19 The left image shows the website page of CLIP API Debugger on[192.168.88.188;\the right image is] using the CLIP API Debugger interface tosend HTTP requests
Querying URL path /api/mJmYjtqYzB4GpX6LewQ6bN067pnxetiVatbO0lVc/revealed a light identifier of ‘1’, which is the light object responsewith detail status information from server.
Figure 20 Retrieving device state information via the CLIP API Debugger
After that, a GET request to this resource confirmed the current stateof the light, and sending a PUT request to the same endpointsuccessfully updated its state to “on”, while the physical lamp alsoturned on.
Figure 21: Clip API request attack.
Mitigations
It was found that unauthorized users could access the RESTful APIinterface and remotely control the smart lighting due to the lack ofproper authentication mechanisms. Therefore, it’s critical to implementrobust authentication and authorization practices, such as deployingsecure API keys, OAuth tokens, or JSON Web Tokens (JWT). These methodsensure that only authorized entities can access sensitive API endpoints,effectively preventing unauthorized remote control of the lightingsystem as observed during our hands-on assessment.
Additionally, utilizing HTTPS instead of HTTP ensures that requestsremain encrypted during transmission, thereby mitigating the risk ofcredentials being intercepted by unauthorized third parties [7].Furthermore, restricting access to administrative functions throughtrusted device allowlists can further enhance the security posture.
Reverse Engineer Find Camera Password (Main Victim: 192.168.88.20)
In this section, reverse engineering is used to decompile and analyzethe target APK package to extract sensitive information (e.g., usernamesand passwords) embedded in the software. Not only was the applicationsuccessfully executed using an Android emulator, but an unauthenticatedwebcam service interface was also discovered. It also discoveredusernames and passwords of administrators and regular users fromconfiguration files and APK package files respectively and successfullyaccessed the protected service from the web side.
Exploitation
Firstly, find the camera tag and port from the imported APK packagewithin Jadx.
Figure 22: Application name and label in AndroidManifest.xml file,extract from apk package by jadx[2].
Figure 23: Discovery the camera service port (8765 or 8081) by keywordsearching.
Figure 24 (left) shows the using of Android Studio and set the config ofcamera and retrieved credentials: URL(http://192.168.88.20), label(PlantEye), port(8765), ensuring a successful connection to the camera feed.After the setup, a live feed can be viewed from the Raspberry Pi camerain Figure 24 (right).
Figure 24 Configuring and accessing a Raspberry Pi-based motionEyecamera via a mobile app
Regarding the connection to the web side, this can be done by firstconnecting to [192.168.88.20] using ssh with the defaultpassword in Figure 25.
Figure 25 Locating and identifying potentially sensitive configurationfiles within a Raspberry Pi camera system
Once this process has gained permission, it is possible to locate theMotionEye configuration file and look for the administrator username andpassword directly from the relevant file.
Figure 26: Ending the motion.conf configuration file and revealing admincredentials
Fill in the admin_username and admin_password in the browser login boxto successfully access the camera web interface.
Figure 27 Logging into the Raspberry Pi camera web interface withadmin’s retrieved credentials
By using the Jadx software again, the app_debug.apk file was importedand the lookup keyword was set to the default username. As a result, thestrings.xml file of the Android application exposes the hard-codeddefault username (‘user’) and password (‘GoPr0NoGo.1337’).
Figure 28 Identifying hardcoded default credentials in an Android app’sresource file
Using the discovered credentials, the user successfully logs into a webinterface streaming from a Raspberry Pi camera.
Figure 29 Logging into the Raspberry Pi camera web interface with user’sretrieved credentials
Mitigations
To mitigate the risk identified, particularly the exposure of camerapasswords through reverse engineering of the application, more targetedsecurity practices should be applied. Specifically, sensitiveinformation such as login credentials and device access passwords shouldnever be hard-coded or plainly embedded within application binaries.Instead, these sensitive details should always be securely encrypted andstored in dedicated secure storage spaces.
Additionally, employing advanced obfuscation methods such as controlflow flattening, identifier renaming, and string encryption will obscurethe logical structure of the app, making it difficult and time-consumingfor potential attackers to locate and extract sensitive information. Andregular security assessments and updating the application’s obfuscationtechniques can consistently counter evolving reverse engineeringmethods, further protecting the system from unauthorized dataextraction.
Strengthening overall communication security is also critical.Implementing secure and encrypted protocols such as HTTPS withappropriate TLS certificates ensures that sensitive data transmittedbetween the application and its backend cannot be intercepted ortampered with during transit.
Mosquitto Sniffing (Victim: 192.168.88.150)
Exploitation
After connecting to 192.168.88.150 by SSH, it demonstrates the runningMosquitto broker process on the device (iot2050-debian) and a client.
Figure 30 Checking running Mosquitto broker processes on the IoT2050host reveals an active MQTT subscription command, showing configurationdetails and topic subscriptions
In Figure 31, it uses the netstat -tupln command to check the servicesthat are running and listening for connections on the server.
Figure 31 Checking active listening services, and result shows a varietyof ports and protocols, confirming that the Python-based service islistening on port 5000
Figure 32 displays the results from checking Mosquitto configurationfiles, identifying two active configuration files: one localconfiguration and one system-wide configuration.
Figure 32 Results of checking Mosquitto configurations on the device
The contents of the system-wide Mosquitto configuration file show thepersistence setting and its designated location for storing persistentdata.
Figure 33 Viewing contents of the Mosquitto system configuration file
The configuration file reveals that anonymous access is permitted onport 1883, indicating that any client can subscribe to or publishmessages without authentication.
Figure 34 Local Mosquitto configuration permitting anonymous access
A Python MQTT client, hosted on IP 192.168.88.143, subscribes to allavailable MQTT topics.
Figure 35 MQTT client at 192.168.88.143 subscribing to all MQTT topicsfrom the Mosquitto broker
Here it checks all the messages, indicating active connections andclient communications involving devices between 192.168.2.130 and192.168.2.50.
Figure 36 Analysis of Mosquitto broker logs
Figure 37 illustrates a Node-RED instance on 192.168.88.50, subscribingto the MQTT topic ip, verifying that device 192.168.2.130 operates as aZigBeeReceiver.
Figure 37 Node-RED instance (192.168.88.50)
Mitigations
Based on the observations and analysis from the practical experiment,the primary security issue arises from Mosquitto’s current configurationpermitting anonymous access on port 1883. This allows any device withinthe network, including unauthorized entities, to connect, subscribe, andpublish messages freely. To address this specific vulnerability,Mosquitto’s configuration must be modified to disable anonymous accessexplicitly. Implementing mandatory username and password authenticationthrough encrypted credential storage or external authentication serviceswould restrict broker access exclusively to authorized and verifieddevices.
Moreover, considering the nature of the practical operations,implementing secure communication channels is essential. Enabling TLSprovides robust encryption for messages exchanged between Mosquittobrokers and clients, ensuring confidentiality and integrity duringtransmission. And practical security enhancement also requires clearlydefined Access Control Lists (ACLs). Based on the report, it shouldexplicitly specify permissions for different clients, determining whichtopics they can publish or subscribe to. By enforcing strict topic-basedaccess policies tailored to industrial IoT environment, it could reducethe attack surface, limiting the risk of unauthorized access ormalicious control over the system.
S7comm Protocol Non-authentication (Main Victim: 192.168.2.10)
The [192.168.2.10] (Siemens PLC) communicates with other IoTdevices through S7comm protocol, which has been reported to containvulnerabilities that leak authentication mechanisms [2, 4]. Thissection leverages the identified vulnerability in the S7Comm protocolto handle a spoofing attack against the PLC. Based on the previouslyobtained reverse shell access to the host at [192.168.88.50](Siemens IoT2050), memory reading operations are performed on the victimto capture real-time states and analyze pin functionalities.Subsequently, a script continuously transmits crafted signals tospecific pins, overwriting legitimate signal content to achieve theintended spoofing effect.
Exploitation
Since the reverse shell of [192.168.88.50] was obtained inSection 3.2, the attacker can read the PLC output signal through thescript shown in Figure 38. This script establishes a connection to thePLC, reads one byte from Q (Output) pin memory at address 0, and printsthe state of the specified bit ([%Q0.2],[%Q0.3]).
Figure 38 Python script using the Snap7 library to connect to theSiemens S7‑1200 PLC at [192.168.2.10] and read the Booleanvalue of bit 3 in the Q output memory area.
It runs through proxychains, indicating that remote memory reads canbe performed through the pivot network path without direct networkaccess (Figure 39).
Figure 39: Proxychains output confirming that the same Snap7 readoperation ([%Q0.2] in left, %[Q0.3] in right)successfully executed.
Experimental testing confirmed that pin [%I10.2], designatedas an input pin, could be successfully written to and read with thetampered value. The following reading loop script in Figure 40 wasutilized to retrieve the value from pin [%I10.2], while theresult of reading pin [%I10.2] is True, shown in Figure41.
Figure 40: The reading loop scripts, using python snap7 library.
Figure 41: The terminal result of reading [%I10.2] pin withthe proxy connection.
Figure 42 shows write script, which rewrite it to false in[%I10.2] at Siemens PLC([192.168.2.10)].
Figure 42: Rewrite python script to PLC. Tampering the true value in%I10.2 to false.
After executing write script, it can be observed that value wassuccessfully changed in Figure 43, the spoofing completed.
Figure 43: Result changed in %I10.2 pin was observed.
Mitigations
By implementing network segmentation, the PLC can be physically orlogically isolated from untrusted networks. Access control should beenforced based on the principle of least privilege, limiting access to apredefined list of authorized devices and operations. This approachsignificantly enhances PLC security by preventing unauthorizedinteractions. However, in the current scenario, a device connected tothe PLC has been compromised and repurposed as a proxy server, enablingindirect access for the attacker. To address such threats, deploying anIntrusion Detection System (IDS) within the internal network isrecommended to monitor and identify suspicious activities—such ashigh-frequency write operations—and trigger alerts accordingly.Additionally, protocol encapsulation techniques may be employed to wrapthe S7Comm protocol with enhanced security features.
Zigbee Key Capture
Zigbee, as the communication protocol between Philips Lamp, Hue andSmart button, has known security vulnerabilities, particularlyconcerning its key management during the device joining process [3,6]. This Section exploit this vulnerability to archive theinformation disclosure.
Exploitation
Firstly, connect the Zigbee sniffer device to a Kali Linux machine fornetwork vulnerability testing.
Figure 45 Capturing ZigBee traffic with Whsniff and Wireshark
Then try re-searching for light on the phone and pairing it and place itinside the kitchen instead of the original living room.
Figure 47 Captured ZigBee handshake packet with the “announcement”keyword, showing the extracted key field for security analysis
Next, continue to operate the APP to switch on and off the light severaltimes, and re-capture the packet, the result shows the packetinformation without adding the key. It can be observed that while somedata packets are transmitted after the “command” field, such as packetnumbers 434 and 435, the actual data remains undetectable.
Figure 48 Captured packets transmitted without adding a key, but dataundetectable
Add a pre-configured ZigBee network key to Wireshark’s preferences todecrypt captured ZigBee packets , allowing for clearer analysis of thenetwork traffic.
Figure 49 Adding the pre-configured ZigBee network key in Wireshark
It can be noted that the previously encrypted ZigBee packet has beensuccessfully decrypted, and the payload can be analysed. The decryptedpayload is now visible under the “Encrypted Payload” section in theWireshark interface.
Figure 50 Decrypted ZigBee data packets, with the payload now visiblefor analysis
Mitigations
The experiment showed that ZigBee encryption keys could be easilyextracted from handshake packets, which directly threatens theconfidentiality of communications. To reduce this risk, static keysshould be avoided, as they can be reused across multiple devices andeasily intercepted. Instead, secure installation procedures should beenforced, including the use of Install Codes, which allow each ZigBeedevice to be paired with a unique, pre-distributed key. This methodensures that even if one pairing session is compromised, other devicesremain secure.
Regular key rotation and disabling insecure open join modes are alsonecessary to prevent long-term exploitation of exposed keys. Wherepossible, upgrading devices to ZigBee 3.0 or newer provides bettersecurity mechanisms, though this may not always be feasible due tohardware constraints. Access to the ZigBee network should be physicallyand logically restricted. Continued monitoring of ZigBee traffic,combined with detection systems that flag unusual device behavior,offers another important layer of protection against unauthorized accessattempts.
Scada Panel Tampering
The NODE-RED interface on IP [192.168.88.50] serves toprogram and control the SCADA system (192.168.88.150) through the WebUI.
Figure 51 NODE-RED interface displaying the connection between ICSdevices and the SCADA server, and receiving messages from the PLC at192.168.2.10.
Figure 51 shows a configuration in Node-RED, where an HTTP request issent to the SCADA system at IP 192.168.88.150:5000, using the GET methodto send a message with the parameter “var_5_title=Conveyor”.
Figure 52 Sending a message to the SCADA system at 192.168.88.150:5000using an HTTP GET request to control or monitor the conveyor.
The payload can be dynamically updated by changing the URL parameters,which now include “var_5_title=Conveyor_State” and “var_5_value=true”.
Figure 53 The payload is dynamically changed by modifying the URLparameters, sending updates to the SCADA system with different values
Mitigations
To prevent unauthorized manipulation of the SCADA system through theNode-RED interface, it is essential to implement role-based accesscontrol (RBAC). This ensures that only authorized users have permissionto access or configure critical flow nodes responsible for communicationwith ICS devices. The HTTP input nodes in Node-RED should be restrictedto accept requests only from whitelisted IP addresses or those thatinclude valid authentication tokens, thereby reducing the risk ofcontrol commands being issued from untrusted or external sources.
Smart Plugin Unauthorized Access
In the terminal, a nmap scan was first executed and port 9999 was foundopen under 192.168.88.186. So the Python script named ‘smart_plug.py’was used several times to get information related to the cloud serviceof this smart socket, including the email address, server address andbinding status.
Figure 54 Remotely control smart socket devices and get informationabout network and cloud services
Conclusion
In this experiment, security risks associated with IoT deviceconfigurations, including tempering, spoofing, weak authentication,insufficient authorization, and sensitive information disclosure, wereidentified and demonstrated. Using tools like Nmap, we identified activedevices on multiple network segments and uncovered key vulnerabilitiessuch as unauthenticated access to Node-RED on port 1880 and weakconfigurations in devices like the Siemens S7-1200 PLC. Recommendationsinclude implementing stronger authentication methods, applying strictauthorization controls, disabling unnecessary services, and regularlyupdating systems. It emphasized the need for proactive security measuresto protect sensitive infrastructure in real-world environments.
REFERENCES
[1] Antonakakis, M. et al. 2017. Understanding the mirai botnet. 26thUSENIX Security Symposium (USENIX Security 17) (Vancouver, BC, Aug.2017), 1093–1110.
[2] Beresford, D. 2011. Exploiting siemens simatic S7 PLCs. Black HatUSA. 16, 2 (2011), 723–733.
[3] Department of Electronic Engineering, Cape Peninsular Universityof Technology, Cape Town, South Africa et al. 2024. Implementingenhanced security in the zigbee joining process using elliptic curvediffie–hellman algorithm. Electrica. 24, 3 (Nov. 2024), 589–600.DOI:https://doi.org/10.5152/electrica.2024.23188.
[4] Hui, H. et al. 2021. Vulnerability analysis of S7 PLCs:manipulating the security mechanism. International Journal of CriticalInfrastructure Protection. 35, (Dec. 2021), 100470.DOI:https://doi.org/10.1016/j.ijcip.2021.100470.
[5] Noman, H.A. and Abu-Sharkh, O.M.F. 2023. Code injection attacks inwireless-based internet of things (IoT): a comprehensive review andpractical implementations. Sensors. 23, 13 (Jan. 2023), 6067.DOI:https://doi.org/10.3390/s23136067.
[6] Wang, W. et al. 2020. Analyzing the attack landscape ofzigbee-enabled IoT systems and reinstating users’ privacy. Proceedingsof the 13th ACM Conference on Security and Privacy in Wireless andMobile Networks (New York, NY, USA, Jul. 2020), 133–143.
[7] Wytrębowicz, J. et al. 2021. Messaging protocols for IoTsystems—a pragmatic comparison. Sensors. 21, 20 (Jan. 2021), 6904.DOI:https://doi.org/10.3390/s21206904.