Uma aplicação web no endereço 10.0.10.20 recebe uma solicitação do notebook do analista (10.0.10.50), enquanto um pico de tráfego posterior, originado em 10.0.30.66, atinge ambas as sub-redes internas. O atacante não precisa fazer login para gerar evidências. Cada pacote registra a origem do tráfego, seu destino e o protocolo utilizado para transportá-lo. A questão para o defensor é como uma sessão capturada pode revelar tanto o tráfego web esperado quanto sondagens suspeitas, sem que a captura seja tratada apenas como um fluxo ilegível de bytes.
Nosso laboratório fixo inclui o notebook do analista e a aplicação web na rede 10.0.10.0/24, um resolvedor DNS em 10.0.10.53 e um banco de dados em 10.0.20.10. Um firewall e roteador conectam essas redes por meio dos endereços 10.0.10.1 e 10.0.20.1; a VM do atacante está localizada separadamente em 10.0.30.66. A captura começa com tráfego DNS e web e, em seguida, inclui a VM do atacante contatando endereços nas duas redes internas. Retornaremos a esses endereços específicos ao longo do curso, garantindo que qualquer filtro ou alerta posterior tenha sempre uma linha de base conhecida.
O diagrama consolida os dispositivos, endereços e o tráfego capturado em um único local:
Este diagrama mostra por que a varredura posterior é importante. Uma solicitação de cliente para a aplicação web tem um propósito esperado, enquanto conexões repetidas de 10.0.30.66 para muitos destinos podem indicar reconhecimento. Se a prevenção falhar e o firewall permitir tráfego indesejado, a captura de pacotes permanece como uma fonte de detecção, pois registra o endereço de origem, o endereço de destino, o protocolo e o momento da ocorrência. A Descoberta de Serviços de Rede (Network Service Discovery) é a técnica T1046 do ATT&CK (versão v20, de outubro de 2026), e os defensores podem detectar seu padrão de rede por meio de logs de firewall, registros de fluxo ou capturas de pacotes.
A solicitação capturada torna-se compreensível quando a analisamos sob a ótica do encapsulamento, o processo de inserir os dados de um protocolo dentro do cabeçalho de outro protocolo. Por exemplo, a solicitação GET /login do navegador exige mais do que apenas o seu texto. A rede também precisa transportar uma porta de destino, um endereço IP de destino e um destino na rede local.
O modelo OSI e o modelo TCP/IP organizam esse mesmo processo de maneiras diferentes. O OSI descreve sete camadas, enquanto o TCP/IP geralmente agrupa o pacote nas camadas de aplicação, transporte, internet e enlace. Nenhum dos modelos constitui uma rede separada; ambos descrevem o quadro Ethernet que o Wireshark registrou.
Para uma solicitação de 10.0.10.50 para 10.0.10.20, quais informações identificam a entrega local, a entrega ao host, o serviço receptor e a página solicitada? A pilha de pacotes abaixo mantém esses limites visíveis:
Esta pilha mostra a resposta de fora para dentro. O Ethernet usa endereços MAC para entregar o quadro através do link local. O IPv4 transporta 10.0.10.50 e 10.0.10.20 para que os roteadores possam encaminhar o pacote entre redes. O TCP usa as portas 51514 e 80 para identificar as extremidades da comunicação, e o HTTP transporta GET /login como dados de aplicação. Assim, um analista de pacotes pode fazer uma pergunta diferente em cada camada, em vez de pesquisar todos os campos de uma só vez.
Ordem dos cabeçalhos Leia os campos do pacote desde a entrega no nível de link, passando pela entrega ao host e pela entrega ao serviço, antes de interpretar a solicitação da aplicação.
Como o quadro contém várias camadas simultaneamente, o painel de detalhes de pacotes do Wireshark as expande como entradas de protocolo separadas. Ethernet II exibe os campos MAC da Camada 2, Internet Protocol Version 4 exibe os endereços da Camada 3 e Transmission Control Protocol exibe as portas e sinalizadores (flags) de controle da Camada 4. Uma entrada Hypertext Transfer Protocol aparece apenas quando o Wireshark consegue identificar dados HTTP visíveis.
Nem todo quadro contém uma solicitação HTTP. Antes do primeiro GET /login, o TCP estabelece a conexão com um SYN vindo de 10.0.10.50 e uma resposta SYN/ACK vinda de 10.0.10.20. Esses pacotes identificam os dois hosts e as portas, mas não transportam nenhuma solicitação de página. A saída de referência abaixo extrai campos do mesmo fluxo, sem pretender representar uma execução real em qualquer sistema: