Forensic Analysis of an IoT ARP Spoofing Attack

Abstract

The Internet of Things (IoT) creates numerous attack opportunities. Address Resolution Protocol (ARP) spoofing (or cache poisoning) attacks allow hackers to impersonate a PC and steal traffic. This attack is commonly used in spy movies and increasingly in IoT environments. To show the procedure of an IoT forensic analysis to an ARP spoofing attack, we simulate an IoT environment using Arduinos (UNO Rev2, NANO 33 IoT) and sensors (keypad module, motion sensor) acting as IoT devices in the network. This is the basis for the presented fictitious case scenario (based on an actual case), in which a former insider helps a hacking group to breach a corporate network and spy on company secrets to sell them to the competition (industrial espionage). This attack scenario increasingly used and possible by novel IoT attack paths damages customers' trust in the company and leads to the loss of secret documents, directly causing significant financial loss for the company. The case scenario shows that forensic analysis can provide valuable evidence. It demonstrates the current danger of newly implemented IoT environments within companies and the dangerous use of standard IoT devices (devices available on the market and ones developed for pen-testing) as entry points for advanced attacks.

Full text

Forensic Analysis of an IoT ARP Spoofing Attack
Sabrina Friedl
Chair of Information Systems
University of Regensburg
Regensburg, Germany
sabrina.friedl@ur.de
G¨
unther Pernul
Chair of Information Systems
University of Regensburg
Regensburg, Germany
guenther.pernul@ur.de
Abstract—The Internet of Things (IoT) creates numerous
attack opportunities. Address Resolution Protocol (ARP) spoofing
(or cache poisoning) attacks allow hackers to impersonate a
PC and steal traffic. This attack is commonly used in spy
movies and increasingly in IoT environments. To show the
procedure of an IoT forensic analysis to an ARP spoofing attack,
we simulate an IoT environment using Arduinos (UNO Rev2,
NANO 33 IoT) and sensors (keypad module, motion sensor)
acting as IoT devices in the network. This is the basis for
the presented fictitious case scenario (based on an actual case),
in which a former insider helps a hacking group to breach a
corporate network and spy on company secrets to sell them
to the competition (industrial espionage). This attack scenario
increasingly used and possible by novel IoT attack paths damages
customers’ trust in the company and leads to the loss of secret
documents, directly causing significant financial loss for the
company. The case scenario shows that forensic analysis can
provide valuable evidence. It demonstrates the current danger
of newly implemented IoT environments within companies and
the dangerous use of standard IoT devices (devices available on
the market and ones developed for pen-testing) as entry points
for advanced attacks.
Index Terms—Digital Forensics, IoT Forensics, Live Forensics,
ARP Spoofing, Attack Simulation
I. INT ROD UC TI ON
The term IoT refers to a network of interconnected comput-
ing devices [1]. While the widespread use of IoT in society
and the workplace is significant, it also presents security risks.
Global malware attacks have remained stagnant from 2020
to 2022, but this is not the case for IoT. A 2023 SonicWall
report highlights the vulnerability of IoT systems, showing
a significant increase in attacks, particularly between 2021
and 2022 [2]. Recent research [3], [4] attributes this to the
lack of software and hardware protection for IoT devices,
coupled with a lack of awareness, making them susceptible
to malicious activities.
ARP spoofing, a well-known network attack technique on
local area networks (LANs), involves sending spoofed ARP
messages to target hosts. This can lead to man-in-the-middle
(MITM) or denial-of-service (DoS) attacks [5]. ARP’s vulner-
ability arises from its lack of message authentication (RFC 826
[6], updated in RFC 5227 [7], 5494 [8]). Consequently, any
host can send an ARP request or response pretending to be
another host. Despite being known for nearly 25 years, longer
than modern threats like Ransomware, it continues to be of
interest in the security community investigating techniques to
detect and mitigate it [9], [10].
In wireless ad hoc networks, such as the IoT, ARP spoofing
is more prevalent due to host variability, easy medium access,
and a lack of security coordination, which can have devastating
effects [5], [11]. The best protection, hard-coding Media
Access Control (MAC) and IP pairs, is often impractical
as participating hosts are unknown beforehand. As ad hoc
networks, including sensor and IoT networks, become more
common, they may lack protections due to the focus on low-
cost, interoperable devices [12]. Despite ARP’s unsuitability
for ad hoc networks [13], it will likely continue being used in
many implementations.
To help mitigate IoT attacks and develop secure IoT en-
vironments, IoT forensics can provide deep insights into the
process and functionality of such attacks. Publicly available
actual case data is challenging to find. Therefore, we simulated
an ARP spoofing attack, along with a use case scenario
(inspired by a real case), to demonstrate the forensic analysis
and the evidence that could be extracted. Additionally, through
the fictitious case scenario, we aim to highlight the creative
use of IoT devices for sophisticated cyber attacks and the need
for companies to consider security measures in new areas. To
address network forensics and demonstrate the potential of
ARP spoofing in IoT, we offer the following contributions.
Contribution 1. We present a break-in attack scenario that
makes use of ARP spoofing enabled by newly implemented
IoT, drawing inspiration from a real case of industrial espi-
onage.
Contribution 2. We establish a testbed to replicate an IoT
environment using two Arduinos (UNO Rev2, NANO 33 IoT)
and two sensors (keypad module, motion sensor) functioning
as IoT devices in the network. This enables the replication of
an ARP spoofing attack on IoT.
Contribution 3. We conduct a forensic investigation and
analysis of the simulated ARP Spoofing attack, demonstrat-
ing the investigative process and identifying the extractable
evidence.
The remainder of the paper is organized as follows. Sec. II
provides related work and motivation for this study. In Sec.
III, we briefly describe the case scenario. Sec. IV details the
setup used for the implementation. Thereafter, in Sec. V, we
present the ARP spoofing attack simulation. Subsequently, the979-8-3503-3036-6/24/$31.00 ©2024 IEEE

experimental results of the IoT forensic analysis are presented
and evaluated in Sec. VI. Finally, Sec. VII discusses and
summarizes the findings.
II. RE LATE D WOR K
Early on Mangut [9] highlight, that various mitigation tech-
niques were developed, but none addressed the attack problem
from a forensic perspective. Thus they developed forensic tools
for mitigating ARP cache poisoning attacks. They validated
these tools by comparing evidence captured before and during
an attack. The mitigation technique involved enabling and
configuring Dynamic Host Configuration Protocol (DHCP)
snooping and Dynamic ARP Inspection (DAI) on a Cisco
switch, which proved effective in their experiments. Later on,
Brown [11] explored a new application of the ARP spoofing
attack that creates a routing loop in a target wireless ad
hoc network. This not only results in a DoS to the attacked
hosts but also causes them to waste energy and occupy the
channel, preventing its use by legitimate traffic. They provided
experimental results and suggestions on how to prevent, detect,
or mitigate the attack. The latest research by Sadineni [14] dis-
cussed the challenge of identifying and correlating artifacts in
network packets to reconstruct attack scenarios during forensic
investigations. They proposed a model called ProvNet-IoT that
uses provenance-based forensics to investigate network-level
attacks in IoT environments. The model, validated using two
publicly available labeled IoT datasets with different attacks,
performed well in identifying selective artifacts to produce
reliable evidence.
Although some efforts have been made to approach a
forensic analysis of an ARP spoofing attack, works within
IoT or wireless ad-hoc environments are scarce. Furthermore,
the proposals presented above provide frugal descriptions of
the forensic analysis procedure and none investigate it within
an industrial espionage scenario. Thus, we provide a novel
and detailed perspective to tackle this research gap and help
advance the field of IoT forensics.
III. CAS E SCE NAR IO
The case scenario presented is a fictitious break-in attack to
perform industrial espionage based on a real case [15].
The managing director of electricAutomobiles has observed
an increase in break-ins at her company and wants to enhance
security to prevent future incidents. She aims to implement a
reporting system that detects movements after working hours
and alerts the security team, using an IoT network. Addition-
ally, she plans to implement a password-based login system
for authorized personnel, with centrally stored passwords that
are changed monthly. The passwords will be compared with
entries in a file at a central location for access. Although aware
of encryption methods, the managing director believes the
effort is not worthwhile as the security system installation itself
already enhances security. She sees encryption as unnecessary
for strengthening the security system.
Bob, a former employee of electricAutomobiles, recently
resigned from his role as a developer due to a disagreement
with his boss regarding salary, title, and position. Their re-
lationship had been strained for some time, and Bob felt
he was being treated unfairly. Seeking revenge, he aimed
to inflict maximum damage on the company. Bob overheard
discussions among employees about the new IoT-supported
intrusion detection system, noting their criticism of the lack of
encryption. Conveniently, he still had access to the company’s
WLAN. Using his private computer, he intercepted data traffic
on the LAN network, which also transmitted data from the IoT
network. After gathering the necessary information, he planned
to break in outside of working hours. With data collected
from the alarm system, he knew when and where people
were in the building. Additionally, he could use a password
obtained from the network traffic to gain entry. Bob intended
to steal confidential documents and sell them to the competitor
company futureAutomotives.
IV. IMP LE ME NTATI ON SE TU P
In this section we provide the testbed setup for the IoT
environment utilized to perform and analyze the ARP spoofing
attack.
A. IoT components
In this scenario, an Arduino UNO Rev2 [16] and an Arduino
NANO 33 IoT [17] function as IoT devices in the network. Pins
serve as connections that establish an interface to the modules.
AMembrane Keypad Module [18] serves as a password input
device attached to the Arduino UNO. It’s a 4x4 matrix module
controlled by eight pins connected to the Arduino, with four
pins for the rows and columns of the module. These occupy
digital pins of the Arduino from six to nine for the rows and
two to five for the columns. On the Arduino NANO, a HC-
SR501 PIR Motion Sensor Module [19] is connected. The right
pin of the sensor supplies power, connected to the Arduino’s
VCC pin (red wire), while the left pin closes the circuit by
connecting to the ground (blue wire). The middle pin, linked
to pin 8 of the Arduino, handles data transfer. A 3.3-volt
operating voltage suffices for the module. As a digital pin, it
transmits only the data ”0” (no movement) or ”1” (movement).
Additionally, a red diode, controlled by digital pin 2 (”on”=1
or ”off”=0), is implemented. It requires a 220Ω series resistor
to prevent excessive current-voltage. This setup allows for the
detection of movements through the glow of the diode. Fig.
1 illustrates the arrangement of the IoT device components,
including sensors.
B. Arduino IDE and Scripts
For programming the micro-controllers, the Arduino IDE
is used, which serves as a development platform [20]. The
code programs used for the motion sensor and the keypad
module are provided through a GitHub repository1. In each
case, the secrets.h file is adapted, and the IP address of the
broker is entered. To enable the upload of the programs, two
libraries are required in the board manager of the Arduino
IDE: the ArduinoMegaAVR library for the Arduino UNO WiFi
1https://github.com/SF1995/IoT-ARP-Spoofing

Fig. 1: IoT environment setup with the Arduino UNO Rev2 and
NANO 33 IoT (including sensors).
Rev2 and the Arduino SAM Boards (32-bits ARM Cortex-
M3) library for the Arduino NANO 33 IoT. They allow the
IDE to interact with the micro-controller. While uploading the
sketch, it is essential to choose the Arduino’s correct library
and the port to which the Arduino is connected under the
”Tools” tab. The results can be read in the serial monitor,
marked by a magnifying glass in the upper right corner of the
IDE.
C. IoT Network Configurations
The IoT network is structured as follows. A virtual machine
(VM) with the same name, which is to simulate a physical
computer, is set up as the central node with the Windows 10
operating system, which also functions as a control device.
Data from the sensors is sent to this node via Message
Queuing Telemetry Transport (MQTT), which is why this VM
is configured as a broker. The two Arduinos used simulate
the sensors with other modules. Actuators are not available.
According to the MQTT model, the Arduinos are utilized as
publishers, generating and sending data to the subscriber’s
central node, representing a star topology.
To set up the network, the installation of Oracle VM and a
VM with the Windows 10 operating system are required first.
The WiFi network adapter should be selected and connected
to a network bridge to act as an independent participant
in the network and get its own IP address. After Windows
10 is installed on the VM, port 8331 should be opened
in preparation for the broker. This is done by creating an
incoming rule in the advanced firewall settings that accepts
incoming messages on this port. To ensure that the VM can
receive and send the dates within the network, a ping command
(e.g., ping <IP address>) should be sent in the Windows
command line (CMD) to another machine as well as from
that machine to the VM. If packets arrive at the destination
in each case, this is a sign that the VM can send data on this
network. If not, you may need to check Oracle VM application
settings or create additional firewall rules. To make sure that
the firewall is not a problem, it can also be switched off
completely. Once the basic functionalities are given, the broker
is installed, whereby there are different providers. For this
scenario, Eclipse Mosquitto is used, which enables subscribe
and publish to perform data communication [21].
V. ARP SPO OFI NG ATTACK SIMULATIO N
The ARP spoofing attack from a hacker perspective is
performed as follows on the basis of a VM network. Data
is sent from a physical device (Arduino) to the central node.
This attempt may not be feasible in a network without VMs.
A. Intruder Configuration
For this case scenario, a VM is created, named intruder,
and configured Kali Linux as the operating system (OS). The
WiFi network adapter should be selected in Oracle VM and
configured as a network bridge by default. ARP spoofing
is performed using the arpspoof command in Kali Linux.
Arpspoof is included in the dsniff package. By the Windows
CMD command arp -a, the cache of the central node can
be shown, which is present at the moment. At this point, the
central node’s ARP cache, which displays the IP address and
MAC address, as in Fig. 2.
Fig. 2: ARP cache development pre and during attack.
Note that in Fig. 2, the MAC address associated with
the router’s IP address (192.186.2.1) is e0-60-66-c3-a4-f4.
Once the pre-configuration is complete, the Arduinos and the
MQTT-broker are started. It should be checked if the MQTT-
broker can receive the messages. The intruder knows the IP
address of the central node and the router’s IP address. This
can be found using tools such as Wireshark. Wireshark is then
started on the intruder to be able to read the messages.
B. MITM and ARP Spoofing Attack
The MITM attack is then carried out with ARP spoof-
ing on the intruder. Wireshark should first be started
on the intruder so that data can be read immediately.
Then we navigate to the program arpspoof (cd ...)
and execute the command arpspoof -i <interface> -t
<router IP><destination IP> in a terminal. -i stands
for the interface (network interface, e.g., eth0 or eth1),
and -t for the communication partners between which the
MITM attack is to be executed. Once the command is
executed correctly, after navigating to the program again
in a new terminal, the arpspoof -i <interface> -t
<target IP><router IP> command is executed. The dif-
ference from the execution before is the message to the
router that <destination IP> is now the IP address of the
intruder. Both commands should not be interrupted during the

attack. Now, any passwords or messages can be transmitted
to the MQTT broker. The MQTT broker also displays these.
However, with Wireshark on the Intruder, the attacker can
now read the message unencrypted since no encryption is per-
formed via MQTT, and this is indicated in Wireshark with the
filter command ip.addr == <host of MQTT-Explorer>.
Then, the message is forwarded to the central node and
displayed on the broker. During the attack, the cache of the
central node looks like in Fig. 2. Additionally, it shows that
the physical address is different compared to the pre-attack
cache under the same IP address. This MAC address is the
one of the Intruder. Fig. 3 shows the output the Intruder could
sniff and the sensors that can be mapped to the data.
Fig. 3: Sniffed output by intruder and mapping to sensors.
C. Promiscuous vs. Monitor Mode
As an alternative to this attack, the promiscuous mode can
be configured on the VM in the network adapter settings,
which allows the VM to read all data packets on the VM
network. In sniffing, there are two different modes; one is
promiscuous mode, and the other is monitor mode. According
to the promiscuous mode operation, all network data, regard-
less of its destination for a specific controller device (the
device on which the packet sniffer is executed), is captured
by the network interface controller (NIC) or wireless NIC in
the case of a Wi-Fi connection. In contrast, in monitor mode,
data is only forwarded to the device destined for a controller
via the MAC address. For other packets, no forwarding takes
place [22].
VI. FO RE NS IC ANA LYSIS
This sections provides the forensic analysis of the previously
performed ARP spoofing attack.
A. Suitable Tools for IoT Network Forensics
Tools are essential for identifying and evaluating hacking
attacks [23]. Packet sniffer or analyzer tools are computer
programs that can intercept incoming and outgoing traffic on a
network and decode the raw packet data as a data stream. This
can uncover details about the activities of devices connected to
the Internet on a LAN. Similarly, packet details can be stored
[22]. Two such suitable programs are Tcpdump and Wireshark.
Both applications are available by default in the Kali Linux
distribution. Due to the graphical interface and color coding of
Wireshark th application is more transparent than Tcpdump,
which in comparison neither labels nor interprets data. The
analysis with Tcpdump has to be done by the user since data
is only available in the raw version [22]. Wireshark is thus
used for the forensic investigation.
For more complex IoT environments additional tools or a
combination of different tools across the phases of the forensic
process can significantly support the forensic investigation.
An extended toolbox could be created using tools such as
Volatility, Encase, nmap, or X-Ways.
B. Experimental Results of IoT Forensic Investigation
Upon detecting the attack and Bob’s intrusion, the company
right away informs and activates the forensic investigation
team assuming the attacker is still on the network. The
team intervenes immediately to prevent the attacker from
removing themselves from the network. The investigation also
involves system administrators to help during the identification
phase. Additionally, an independent VM called ”forensic”
is implemented in the network. In Fig. 4 the investigation
process is visualized, including the steps (1) Identification,
(2) Collection, (3) Reduction, (4) Analysis, and (5) Report.
Following each process step is detailed.
Fig. 4: An overview of the investigative process (BPMN notation)
[24].
1) Identification: During this phase, the investigative team
aims to swiftly identify all equipment that can provide insight
into the incident [25]. Simultaneously, promiscuous mode
is enabled to access the traffic from all network machines.
Wireshark is utilized to pinpoint devices and record network
activity. After the recording process, which may take some
time, the team gains an overview of all network components

in the initial identification phase. The central node is given
priority for identification. The subsequent ARP responses
sent back to a network component (refer to Fig. 3) reveal
the IP addresses 192.168.2.126 (MAC: 08:00:37:d4:54:50),
192.168.2.173 (MAC: 78:21:84:7b:40:b0), 192.168.2.132
(MAC: 08:00:27:a4:0a:3f), and 192.168.2.164 (MAC:
08:00:27:b5:a7:ef). The latter represents the forensic device’s
IP address, discovered through the ifconfig command in
the machine’s terminal. However, this VM is not the focus of
the current investigation. Two devices repeatedly send MQTT
messages to the same instance (IP: 192.168.2.132, MAC:
08:00:27:a4:0a:3f), indicating that this instance serves as the
central node.
Several broadcasts are observed using the ARP protocol
from the MAC address e0:60:66:c3:a4:f4 with the IP address
192.168.2.1. Upon consulting the system administrators of the
company electricAutomobiles, it was confirmed that this MAC
address belongs to the router, responsible for managing ARP
responses within the network through ARP tables and receiv-
ing ARP responses when necessary (see Fig. 5). Additionally,
it is evident that two devices repeatedly send MQTT messages
to the central node, indicating that these devices are sen-
sors, Sensor 1: IP= 192.168.2.135, MAC= ec:62:60:81:11:98,
Sensor 2: IP= 192.168.2.173, MAC= 78:21:84:7b:40:b0. This
inference is supported by an analysis of the MQTT protocol
(see Fig. 3). Furthermore, it is possible to identify which
device serves as the motion sensor and which one functions
as the membrane keypad module.
Fig. 5: Extraction of the ARP table of the forensic device.
All evidence, such as the Wireshark records and ARP
caches, are backed up and documented. There are no intrusion
detection systems from electricAutomobiles, and the network
traffic monitoring system Wireshark is used to identify the
network components, and no supporting systems are available.
It is also possible to create a digital evidence map, which
provides an overview of the network and is beneficial, regard-
less of the network size (see Fig. 6). Except for IP address
192.168.2.126 ”Unknown Device”, all devices are identified.
2) Data collection: Since the attacker may still be in the
system, router and network information are needed as soon
as possible, as well as other evidence from other network
interfaces. Since Wireshark has already been used in the
identification phase, the pcabng file created is also backed
up during data collection. Another source of information is
tracing data from the router. As with Wireshark, these are
initialized and then executed on the LAN network over a
certain period. The result is a pcab file that is safely stored.
Fig. 6: Evidence map.
Since the components are known, Firewall logs of the central
node can now be collected and stored. The creation of log
files should be made possible in advance. The sensors do not
have log files. Further, it is important to ensure that the log
files are saved with a timestamp, location, and metadata. Only
a live collection method of the network is possible here since
the data must be collected immediately, otherwise, it may be
challenging or impossible to retrieve relevant data.
3) Data reduction: Filters, mechanisms and classifications
to reduced data are not applied due to the small amount of
data in our case.
4) Data analysis: First, the pcab file of the router
is inspected. Filters such as ”mqtt”, ”tcp” (MQTT is
based on TCP and may be identified with this protocol),
”192.168.2.132”, ”192.168.2.135” or ”192.168.2.173” can
be used to restrict the display. Yet, none of these filters can
detect a message containing ”password” or ”movement”.
However, the file is preserved but documented and sufficiently
secured. The next step is to inspect the firewall log file. This
is relevant because it can provide a temporal reference. Data
is displayed in a raw format, so filter mechanisms are used.
For analysis purposes, several commands are listed one after
the other by so-called pipes and executed together. With the
compound command cat pfirewall- 3.1.log | grep
2023-07-14 | grep TCP | grep -v "192.168.2.132
192.168.2.132" | grep 192.168.2.132 | grep
1883 only the relevant data is displayed. Fig. 7 shows that
no records were obtained between 22:11 and 22:49. The
actual attack was performed between 22:12 and 22:19. This
suggests that no firewall entries occurred during the ARP
spoofing attack. This evidence can be used to answer the
question about the crime time supporting the investigative
reconstruction.
Fig. 7: Log extraction of the firewall.
The final piece of evidence in this investigation are files
recorded with Wireshark. When filtering according to MQTT,
no evidence can be presented since either the IP and MAC
address of the keypad module or the motion sensor are named
as the source, and the destination address is the broker in
each case (ping requests and ping responses are disregarded).

When filtering by ARP protocol, the ARP tables are again
output. However, Wireshark displays a message in the Info
column stating that a duplicate use of the IP address of
the broker (192.168.2.132) has occurred. Under the header
”Address Resolution Protocol” this packet can be specified in
more detail. Fig. 8 shows the information and the header. In
the header there are two yellow colored lines, indicating two
MAC addresses for the IP address 192.168.2.1 and, again two
MAC addresses for the IP address 192.168.2.132. From the
identification phase, it is known that the broker has the IP ad-
dress 192.168.2.132 and the MAC address 08:00:27:a4:0a:3f.
Also known is the IP address (192.168.2.1) and MAC address
(e0:60:66:c3:a4:f4) of the router. The other MAC address
(08:00:37:d4:54:50) is present in both headers and can be
assigned to the IP address 192.168.2.126. This is the ”unkown
device” in the evidence map during the identification phase.
Fig. 8: ARP tables with headers.
Further evidence is provided by the ARP caches from Fig.
2, which were also created during the identification phase and
make it clear that the router’s MAC address has changed.
This evidence indicates that ARP spoofing was performed.
The attacker uses the IP address of the broker to falsely
tell the router that it has the IP address of the broker. The
broker, in turn, falsely said that the attacker had the router’s
IP address. Thus, traffic is routed through the attacker, who
can read the data. Through this realization, the functional
assignment, namely through ARP spoofing, has been clari-
fied. The relationship-oriented assignment is done with the
help of the questions ”Who”, ”What” and ”Where”. With
the knowledge about IP address and MAC address through
forensic analysis, the question of ”who” can be answered. The
attack led to the redirection of communication between the
broker and the router, which answers ”What” and ”Where”. A
temporal assignment is made by analyzing the firewall logs,
which answers the question of ”When”.
5) Results report: In the result report, all evaluation data
are presented and sufficiently explained, so that non-forensic
experts can understand how the attack happened. We pro-
vided the detailed description through the previous phases.
In conclusion, the attacker used ARP spoofing. The attacker
has the IP address 192.169.2.126 and the MAC address
08:00:37:d4:54:50. He must have had access to the network.
The attacker may have logged into the WLAN with a password
indicating that he is an employee or former employee. This
information is forwarded to the appropriate authorities for
further investigation and to take actions.
6) Challenges: Several issues may arise during the execu-
tion of the case scenario. For example, the script may fail
to upload if the Arduino IDE is unable to locate a port. In
the event of such an error, we learned the board should be
disconnected from the computer and then reconnected before
attempting the upload again. Furthermore, it is possible for
one or both Arduinos to become disconnected from the broker
while the case scenario is running. If this happens, the scenario
should be executed again, and the sensors restarted. There may
also be a problem with the broker, in which case Mosquitto
should be restarted in the ”Services” program (on Windows).
If additional errors occur, it is advisable to review the network
configurations.
VII. SUM MA RY
The demonstrated case scenario emphasizes the importance
of a swift response following an attack. Without this, the foren-
sic investigative team would not have been able to identify the
evidence mentioned, making live forensics an essential proce-
dure for this type of attack. Mapping two MAC addresses to
one IP address in the Wireshark recording would not have been
possible if the attacker had already exited the network. The
significance of rapid intervention in such situations is evident.
In reality, there are more complex, diverse, and demanding
scenarios. For instance, in this case scenario, only two micro-
controllers were used. However, in practice, a significantly
larger number of sensors may be used, which would primarily
influence the identification phase. Consequently, the evidence
map can be considerably larger or even infeasible. If the attack
did not occur between the router and broker but between the
sensor and router, the effort for the investigative team would be
significantly higher because in a network with many sensors,
every communication connection would have to be checked.
Another issue arises when the sensors are located in a Body
Area Network (BAN). This case scenario only refers to a
LAN network. When communicating with several different
networks, they would have to be checked for relevance in the
identification phase. In our case, metadata from Arduino’s is
not required but also not created. The absence of these values
can lead to problems, this should already be addressed when
designing an IoT network to ensure that metadata is generated
and transferred to the broker.
To partly solve before mentioned challenges, in future work,
we want to investigate forensics-by-design methods and their
impact on forensic investigations in IoT systems. This enables
a certain level of readiness which can facilitate, ease and create
cost-efficient future investigations. Another research potential
lies in the acquisition of evidence that is located near or on a
person (BAN) in combination with IoT environments (e.g., in
a company). Due to the very flexible networks connections in
the IoT and the sometimes unclear locations at a certain point
in time (timeline creation), it can be hard to map personal
IoT to company IoT. We plan to further research this in
the area of Bring-Your-Own-Device (BYOD) as here similar
problems arise. In addition, the self-configured devices often
pose a higher security risk and gateway for attacks than the
company’s own hardware and software, which is managed and
configured by qualified IT personnel.

REF ER EN CES
[1] M. Stoyanova, Y. Nikoloudakis, S. Panagiotakis, E. Pallis, and E. K.
Markakis, “A survey on the internet of things (iot) forensics: challenges,
approaches, and open issues,” IEEE Communications Surveys & Tuto-
rials, vol. 22, no. 2, pp. 1191–1221, 2020.
[2] A. Petrosyan, “Global monthly number of iot cyber attacks 2020-
2022.” https://www.statista.com/statistics/1322216/worldwide-internet-
of-things-attacks/, April 2023. Accessed: 15.09.2023.
[3] S. Hameed, F. I. Khan, and B. Hameed, “Understanding security re-
quirements and challenges in internet of things (iot): A review,” Journal
of Computer Networks and Communications, vol. 2019, pp. 1–14, 2019.
[4] A. E. Omolara, A. Alabdulatif, O. I. Abiodun, M. Alawida, A. Alab-
dulatif, H. Arshad, et al., “The internet of things security: A survey
encompassing unexplored areas and new insights,” Computers & Secu-
rity, vol. 112, p. 102494, 2022.
[5] S. M. Morsy and D. Nashat, “D-arp: An efficient scheme to detect and
prevent arp spoofing,” IEEE Access, vol. 10, pp. 49142–49153, 2022.
[6] D. C. Plummber, “An ethernet address resolution protocol. rfc 826.”
https://datatracker.ietf.org/doc/html/rfc826, November 1982. Accessed:
11.10.2023.
[7] S. Cheshire, “Ipv4 address conflict detection. rfc 5227.”
https://datatracker.ietf.org/doc/html/rfc5227, July 2008. Accessed:
11.10.2023.
[8] J. Arkko and C. Pignataro, “Iana allocation guidelines
for the address resolution protocol (arp). rfc 5494.”
https://datatracker.ietf.org/doc/html/rfc5494, April 2009. Accessed:
11.10.2023.
[9] H. A. Mangut, A. Al-Nemrat, C. Benza¨
ıd, and A.-R. H. Tawil, “Arp
cache poisoning mitigation and forensics investigation,” in 2015 IEEE
Trustcom/BigDataSE/ISPA, vol. 1, pp. 1392–1397, 2015.
[10] S. Jadhav, A. Thakur, S. Nalbalwar, S. Shah, and S. Chordia, “Detection
and mitigation of arp spoofing attack,” in International Conference
On Innovative Computing And Communication, pp. 383–396, Springer,
2023.
[11] J. D. Brown and T. J. Willink, “A new look at an old attack: Arp spoofing
to create routing loops in ad hoc networks,” in Ad Hoc Networks: 9th
International Conference, AdHocNets 2017, Niagara Falls, ON, Canada,
September 28–29, 2017, Proceedings, pp. 47–59, Springer, 2018.
[12] S. Quanjiang, S. Yan, Y. Xiaohu, L. Tinghui, H. Daojing, and
Y. Guisong, “Large scale firmware analysis for open source components,
hard coding and weak passwords,” in 2021 IEEE International Confer-
ence on Consumer Electronics and Computer Engineering (ICCECE),
pp. 232–236, IEEE, 2021.
[13] P. Phetchai, J. David Ndibwile, D. Fall, S. Kashihara, and S. Tuarob,
“Securing low-computational-power devices against arp spoofing attacks
through a lightweight android application,” in 2017 21st International
Computer Science and Engineering Conference (ICSEC), pp. 1–6, 2017.
[14] L. Sadineni, E. S. Pilli, and R. B. Battula, “Provnet-iot: Provenance
based network layer forensics in internet of things,” Forensic Science
International: Digital Investigation, vol. 43, p. 301441, 2022.
[15] Innovation-Origins, “Chinese cyber espionage exposes years-long
grip on dutch chip giant.” https://innovationorigins.com/en/chinese-
cyber-espionage-exposes-years-long-grip-on-dutch-chip-giant/, Novem-
ber 2023. Accessed: 11.01.2024.
[16] Arduino-Store, “Arduino uno wifi rev2.”
https://store.arduino.cc/products/arduino-uno-wifi-rev2, December
2023. Accessed: 10.12.2023.
[17] Arduino-Store, “Arduino nano 33 iot.”
https://store.arduino.cc/products/arduino-nano-33-
iot?queryID=undefined, December 2023. Accessed: 10.12.2023.
[18] Instructables, “Connecting a 4 x 4 membrane keypad to an ar-
duino.” https://www.instructables.com/Connecting-a-4-x-4-Membrane-
Keypad-to-an-Arduino/, December 2023. Accessed: 05.12.2023.
[19] Reichelt-Store, “Hc-sr501 - infrared motion sensor.”
https://www.reichelt.de/raspberry-pi-infrarot-bewegungsmelder-pir-
hc-sr501-rpi-hc-sr501-p224216.html, December 2023. Accessed:
10.12.2023.
[20] L. Aljundi, “Using the arduino software (ide).”
https://docs.arduino.cc/learn/starting-guide/the-arduino-software-ide,
January 2024. Accessed: 11.01.2024.
[21] Eclipse-Mosquitto, “Eclipse mosquitto™ - an open source mqtt broker.”
https://mosquitto.org/, December 2023. Accessed: 05.12.2023.
[22] P. Goyal and A. Goyal, “Comparative study of two most popular packet
sniffing tools-tcpdump and wireshark,” in 2017 9th International Con-
ference on Computational Intelligence and Communication Networks
(CICN), pp. 77–81, IEEE, 2017.
[23] V. Corey, C. Peterman, S. Shearin, M. S. Greenberg, and J. Van Bokke-
len, “Network forensics analysis,” IEEE Internet computing, vol. 6,
no. 6, pp. 60–66, 2002.
[24] SAP-Signavio, “Sap signavio process collaboration, bpmn 2.0 process
modeling tool,” 2024. Accessed: 02.01.2024.
[25] E. Casey, Digital evidence and computer crime: Forensic science,
computers, and the internet. Academic press, 2011.