Una aplicación web en 10.0.10.20 recibe una solicitud desde el portátil del analista (10.0.10.50), mientras que una ráfaga posterior de tráfico procedente de 10.0.30.66 se dirige a ambas subredes internas. El atacante no necesita iniciar sesión para generar evidencia. Cada paquete registra el origen del tráfico, su destino y el protocolo utilizado para su transporte. La cuestión para el defensor es cómo una sesión capturada puede revelar tanto el tráfico web esperado como intentos de sondeo sospechosos, sin tener que interpretar la captura simplemente como un flujo ilegible de bytes.
Nuestro laboratorio fijo incluye el portátil del analista y la aplicación web en la red 10.0.10.0/24, un resolutor DNS en 10.0.10.53 y una base de datos en 10.0.20.10. Un cortafuegos y un enrutador conectan dichas redes a través de 10.0.10.1 y 10.0.20.1, mientras que la máquina virtual (VM) del atacante se encuentra en una ubicación separada, en 10.0.30.66. La captura comienza con tráfico DNS y web, e incluye posteriormente a la VM del atacante contactando direcciones en ambas redes internas. Volveremos a utilizar estas direcciones específicas a lo largo del curso, de modo que cualquier filtro o alerta posterior cuente siempre con una línea base conocida.
El diagrama muestra la ubicación de los dispositivos, las direcciones y el tráfico capturado:
Este diagrama muestra por qué el escaneo posterior es relevante. Una solicitud de cliente a la aplicación web tiene un propósito esperado, mientras que las conexiones repetidas desde 10.0.30.66 hacia múltiples destinos pueden indicar una fase de reconocimiento. Si la prevención falla y el cortafuegos permite tráfico no deseado, la captura de paquetes sigue siendo una fuente de detección, ya que registra la dirección de origen, la dirección de destino, el protocolo y la información temporal. La técnica de “Network Service Discovery” (Descubrimiento de servicios de red) corresponde a la técnica T1046 de ATT&CK (versión v20, octubre de 2026), y los defensores pueden detectar su patrón de red mediante registros del cortafuegos, registros de flujo o capturas de paquetes.
La solicitud capturada se vuelve comprensible cuando la analizamos mediante la encapsulación, el proceso de colocar los datos de un protocolo dentro del encabezado de otro. Por ejemplo, la solicitud GET /login del navegador requiere más que su simple texto; la red también debe transportar información sobre el puerto de destino, la dirección IP de destino y el destino en la red local.
Los modelos OSI y TCP/IP organizan este mismo proceso de manera diferente. El modelo OSI describe siete capas, mientras que el TCP/IP suele agrupar el paquete en las capas de aplicación, transporte, internet y enlace. Ninguno de los modelos constituye una red independiente; ambos describen la trama Ethernet que registró Wireshark.
Para una solicitud desde 10.0.10.50 hacia 10.0.10.20, ¿qué información identifica la entrega local, la entrega al host, el servicio receptor y la página solicitada? La pila de protocolos del paquete que se muestra a continuación permite visualizar dichos límites:
Esta pila muestra la respuesta desde el exterior hacia el interior. Ethernet utiliza direcciones MAC para entregar la trama a través del enlace local. IPv4 transporta 10.0.10.50 y 10.0.10.20 para que los enrutadores puedan reenviar el paquete entre redes. TCP utiliza los puertos 51514 y 80 para identificar los puntos finales de la comunicación, y HTTP transporta GET /login como datos de aplicación. Por lo tanto, un analista de paquetes puede plantear una pregunta diferente en cada capa en lugar de buscar en todos los campos simultáneamente.
Orden de las cabeceras Lea los campos del paquete desde la entrega a nivel de enlace, pasando por la entrega al host y la entrega del servicio, antes de interpretar la solicitud de la aplicación.
Dado que la trama contiene varias capas a la vez, el panel de detalles de paquetes de Wireshark las despliega como entradas de protocolo independientes. Ethernet II muestra los campos MAC de la capa 2, Internet Protocol Version 4 muestra las direcciones de la capa 3 y Transmission Control Protocol muestra los puertos y las banderas de control de la capa 4. La entrada Hypertext Transfer Protocol solo aparece cuando Wireshark puede identificar datos HTTP visibles.
No todas las tramas contienen una solicitud HTTP. Antes del primer GET /login, TCP establece la conexión mediante un paquete SYN desde 10.0.10.50 y una respuesta SYN/ACK desde 10.0.10.20. Esos paquetes identifican los dos hosts y puertos, pero no transportan ninguna solicitud de página. La salida de referencia que aparece a continuación extrae campos del mismo flujo, sin pretender que se ejecuten en ningún sistema: