12.4.1.1 Práctica de laboratorio Alt: Interpretar datos HTTP y DNS para aislar al actor de la amenaza

Última actualización: octubre 17, 2022

12.4.1.1 Práctica de laboratorio: Interpretar datos HTTP y DNS para aislar al actor de la amenaza (versión para el instructor)

Nota para el instructor: Los elementos con color de fuente rojo o resaltados en gris indican texto que aparece solo en la copia del instructor.

Objetivos

En esta práctica de laboratorio, analizarán registros durante un aprovechamiento malicioso de vulnerabilidades HTTP y DNS documentadas.

Parte 1: Preparar el entorno virtual
Parte 2: Investigar un ataque de Inyección SQL
Parte 3: Analizar una exfiltración de datos

Antecedentes / Escenario

MySQL es un sistema de administración de bases de datos relacionales (Relational Database Management System, RDBMS) que utiliza el lenguaje de consultas estructurado (Structured Query Language, SQL) para agregar contenido a una base datos, acceder a él y administrarlo. MySQL es un RDBMS popular que utilizan numerosas aplicaciones web. Desafortunadamente, un atacante puede emplear una técnica de hacking web llamada inyección SQL para ejecutar comandos SQL maliciosos en un intento por controlar el servidor de bases de datos de una aplicación web.

Los servidores de nombres de dominio (Domain Name Servers, DNS) son directorios de nombres de dominio y traducen los nombres de dominio a direcciones IP. Este servicio puede utilizarse para exfiltrar datos.

En esta práctica de laboratorio investigarán una posible inyección SQL para acceder a la base de datos SQL del servidor. También analizarán los registros para investigar una posible exfiltración de datos y el método de exfiltración.

Recursos necesarios

• Servidor con al menos 3 GB de RAM y 10 GB de espacio libre en disco.
• Versión más reciente de Oracle VirtualBox
• Conexión a Internet
• Una máquina virtual: VM Security Onion alternativa

Parte 1: Preparar el entorno virtual

a. Descarguen la máquina virtual Security Onion alternativa.

b. Abran Oracle VirtualBox. Importen la VM Security Onion alternativa.

c. Abran la VM Security Onion e inicien sesión. Inicien sesión con el usuario analyst y la contraseña cyberops.

d. En la VM Security Onion alternativa, hagan clic derecho en el Escritorio > Open Terminal Here (Abrir terminal aquí). Introduzcan el comando sudo service nsm status para verificar que todos los servidores y sensores estén listos. Este proceso podría demorar unos instantes. Si algunos servicios reportan una falla (FAIL), repitan el comando según sea necesario hasta que todos los estados sean OK antes de pasar a la parte siguiente.

analyst@SecOnion:~/Desktop$ sudo service nsm status
Status: securityonion
  * sguil server                                                          [ OK ]
Status: HIDS
  * ossec_agent (sguil)                                                   [ OK ]
Status: Bro
Name            Type    Host             Status    Pid    Started
manager         manager localhost        running   5577   26 Jun  10:04:27
proxy           proxy   localhost        running   5772   26 Jun  10:04:29
seconion-eth0-1 worker  localhost        running   6245   26 Jun  10:04:33
seconion-eth1-1 worker  localhost        running   6247   26 Jun  10:04:33
seconion-eth2-1 worker  localhost        running   6246   26 Jun  10:04:33
Status: seconion-eth0
  * netsniff-ng (full packet data) [ OK ]
  * pcap_agent (sguil) [ OK ]
  * snort_agent-1 (sguil) [ OK ]
  * snort-1 (alert data) [ OK ]
  * barnyard2-1 (spooler, unified2 format) [ OK ]
<output omitted>

Parte 2: Investigar un ataque de Inyección SQL

Cuando analizaron el registro de Sguil, notaron que había un posible ataque de Inyección SQL. Investigarán los eventos para determinar la gravedad del posible aprovechamiento malicioso.

Paso 1: Analicen los registros de Sguil.

a. Diríjanse a la VM Security Onion alternativa. Haga doble clic en el icono de Sguil del Escritorio. Introduzcan el nombre de usuario analyst y la contraseña cyberops cuando el sistema se los solicite.

b. Hagan clic en Select All (Seleccionar todas) para monitorear todas las redes. Hagan clic en Start SGUIL (Iniciar SGUIL) para continuar.

c. En la ventana inferior derecha de la consola de Sguil, hagan clic en Show Packet Data (Mostrar datos de paquetes) y en Show Rule (Mostrar regla) para ver los detalles de una alerta seleccionada.

d. Busquen alertas relacionadas con ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT. Seleccionen las alertas que comiencen con 5. Estas alertas están relacionadas con seconion-eth1-1, y probablemente sean las más recientes. Seleccionen las alertas con el siguiente ID: 5836.

e. Hagan clic derecho sobre el número que se encuentra debajo del encabezado de CNT correspondiente a la alerta seleccionada para ver todas las alertas relacionadas. Seleccionen View Correlated Events (Ver eventos correlacionados).

f. Hagan clic en el ID de una alerta en los resultados. Seleccionen Transcript (Transcripción) para ver los detalles correspondientes a esta alerta.

g. En esta ventana pueden ver que la declaración GET que está utilizando el operador UNION se empleó para acceder a la información de tarjetas de crédito. Si no ven esta información, hagan clic derecho sobre otro de los eventos correlacionados.

¿Qué información pueden reunir de la ventana Transcript?
En la ventana Transcript se muestra la transacción entre el origen 209.165.201.17:47144 y el destino 209.165.200.235:80. La transcripción indica que 209.165.201.17 está tratando de acceder a información de tarjetas de crédito por medio de un operador SQL UNION. La transcripción correspondiente al servidor web en 209.165.200.235 muestra el contenido HTML que se expuso al atacante.

h. También puede determinar la información que recuperó el atacante. Hagan clic en Search (Buscar) e introduzcan username (nombre de usuario) en el campo Find: (Buscar:). Utilicen el botón Find para encontrar la información capturada. La misma información de tarjetas de crédito puede aparecer en pantalla con un aspecto distinto al de la figura de abajo.

Comparen la información de las tarjetas de crédito de la ventana de la transcripción con el contenido que se extrajo con el ataque de Inyección SQL. ¿Qué pueden concluir?
La información de tarjetas de crédito es la misma porque en la transcripción se muestra todo el contenido transmitido entre el origen y el destino.

i. Cierren las ventanas cuando hayan terminado.

j. Regresen a la ventana de Sguil, hagan clic derecho sobre el mismo ID de alerta que contiene la información de tarjetas de crédito exfiltrada y seleccionen Wireshark.

k. Hagan clic derecho sobre un paquete TCP y seleccionen Follow TCP Stream (Seguir flujo de TCP).

l. En la ventana del flujo de TCP se muestran la solicitud GET y los datos exfiltrados. Sus salidas pueden diferir de la figura de abajo, pero tiene que contener la misma información de tarjetas de crédito que la transcripción anterior.

m. En este punto podrían guardar los datos de Wireshark si hacen clic en Save As (Guardar como), en la ventana del flujo de TCP. Como alternativa, también pueden guardar el archivo pcap de Wireshark. También pueden documentar las direcciones IP y los puertos de origen y destino, la hora del incidente y el protocolo utilizado para el análisis subsiguiente a cargo de un analista Nivel 2.

n. Cierren o minimicen Wireshark y Sguil.

Paso 2: Analicen los registros de ELSA.

Los registros de ELSA también pueden proporcionar información similar.

a. Cuando estén en la VM Security Onion, hagan doble clic para iniciar ELSA desde el Escritorio. Si ven el siguiente mensaje: «Your connection is not private» («Su conexión no es privada»), hagan clic en ADVANCED (AVANZADAS) para continuar.

b. Hagan clic en Proceed to localhost (unsafe) (Proseguir a un host local [inseguro]) para continuar al host local.

c. Inicien sesión con el nombre de usuario analyst y la contraseña cyberops. Ahora realizarán una consulta para buscar una Inyección SQL HTTP de la alerta de Sguil.

d. En el panel izquierdo, seleccionen HTTP > Top Potential SQL Injection (HTTP > Principales inyecciones SQL potenciales).

e. Haga clic en el campo Desde y seleccione 11/11/17 como la fecha. Hagan clic en Submit Query (Enviar consulta). Seleccionen 209.165.200.235.

f. Se abre información detallada de la alerta. Esta información está relacionada con la inyección SQL exitosa. Observen la consulta union que se utilizó durante el ataque. En la primera entrada, haga clic en Info.

g. Hagan clic en Plugin > getPcap (Complemento > getPcap). Introduzcan el nombre de usuario analyst y la contraseña cyberops cuando el sistema se los solicite. Si es necesario, hagan clic en Submit (Enviar). CapMe es una interfaz web que les permite obtener una transcripción pcap y descargar el pcap.

h. La transcripción de pcap se traduce utilizando tcpflow, y esta página también proporciona el enlace para acceder al archivo pcap. También pueden buscar información sobre el nombre de usuario. Presionen Ctrl + F para abrir el cuadro de diálogo Find… (Buscar…). Introduzcan el nombre de usuario en el campo. Deberían poder localizar la información de tarjetas de crédito que se expuso durante el ataque de inyección SQL.

Parte 3: Analizar una exfiltración de datos

Cuando analizaron los registros de ELSA, notaron que había algunas solicitudes de DNS extrañas. Si meta es determinar si se exfiltró algún dato durante el aprovechamiento malicioso.

a. Si es necesario, abra ELSA desde el Escritorio de la VM alternativa Security Onion. Si ven el siguiente mensaje: «Your connection is not private» («Su conexión no es privada»), hagan clic en ADVANCED (AVANZADAS) para continuar. Hagan clic en Proceed to localhost (unsafe) (Proseguir a un host local [inseguro]) para continuar al host local. Introduzcan el nombre de usuario analyst y la contraseña cyberops cuando el sistema se los solicite.

b. En las consultas de ELSA de la barra lateral izquierda, hagan clic en DNS > Bottom (DNS > Menos frecuentes).

c. Haga clic en el campo Desde y seleccione 11/11/17 como la fecha. Hagan clic en Submit Query (Enviar consulta). Esto devuelve registros correspondientes a todas las solicitudes de DNS, ordenados de modo que los menos frecuentes aparezcan primero.

d. Desplácense hacia abajo por la lista de resultados para ver algunas consultas de ns.example.com con una cadena hexadecimal como primera parte del nombre de subdominio. Habitualmente, los nombres de dominio no son expresiones hexadecimales de 63 bytes. Esto podría indicar la presencia de actividad maliciosa porque los usuarios probablemente no pueden recordar un nombre de subdominio largo con letras y número aleatorios.

e. Hagan clic en uno de los enlaces y copien la cadena de 63 bytes preanexada a example.com.

f. Abran una ventana del terminal y utilicen los comandos echo y xxd para revertir la cadena hexadecimal. La opción -n impide la salida de la línea nueva de arrastre.

analyst@SecOnion:~/Desktop$ echo -n "434f4e464944454e5449414c20444f43554d454e540a444f204e4f542053" | xxd -r -p
CONFIDENTIAL DOCUMENT
DO NOT Sanalyst@SecOnion:~/Desktop$

¿Cuál es el resultado si siguen revirtiendo las cadenas hexadecimales?
El resultado es:
CONFIDENTIAL DOCUMENT
NO COMPARTIR
Este documento contiene información sobre la última brecha de seguridad.
Este fue el contenido del documento que se filtró utilizando DNS.