ExamenRedes – Examen, preguntas y respuestas Redes De Computadores Examenes de Redes
Última actualización: octubre 18, 2022
12.4.1.2 Práctica de laboratorio: Host comprometido aislado utilizando el método de cinco tuplas (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 revisarán archivos de registro durante el ataque a una vulnerabilidad documentada para determinar los hosts y el archivo comprometidos.
Parte 1: Preparar el entorno virtual
Parte 2: Revisar los archivos de registro
Antecedentes / Escenario
Los administradores de TI utilizan 5-Tuple cuando necesitan identificar los requisitos necesarios para crear un entorno de red operativo y seguro. Los componentes de 5-Tuple son los siguientes: la dirección IP y el número de puerto de origen, la dirección IP y el número de puerto de destino y el protocolo en uso.
En esta práctica de laboratorio también revisarán los archivos de registros para identificar los hosts comprometidos y el contenido del archivo afectado.
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í). Introduzca 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: Revisar los archivos de registro
Después del ataque, los usuarios ya no pueden acceder al archivo de nombre confidential.txt. Ahora revisarán los archivos de registro para determinar de qué manera se vio afectado el archivo.
Nota: Si esta red fuese de producción, se recomienda que los usuarios analyst y root cambien sus contraseñas y cumplan con la política de seguridad vigente.
Paso 1: Revisar alertas en Sguil
a. Abran Sguil e inicien sesión. Hagan clic en Select All (Seleccionar todo) y, luego, en Start SGUIL (Iniciar SGUIL).
b. Revisen los eventos que aparecen en la lista de la columna Event Message (Mensaje de eventos). Dos de los mensajes son GPL ATTACK_RESPONSE id check returned root. Estos mensajes indican que es posible que se haya obtenido acceso raíz durante un ataque. El host de 209.165.200.235 devolvió el acceso raíz a 209.165.201.17. Seleccionen las casillas de verificación Show Packet Data (Mostrar datos del paquete) y Show Rule (Mostrar regla) para ver cada alerta más detalladamente.
c. Seleccionen el mensaje de raíz devuelto asociado con el Sensor seconion-eth1-1 para profundizar el análisis. En la figura de abajo, se utiliza el ID de alerta 5.5846 y sus eventos correlacionados.
d. Hagan clic en el número que se encuentra debajo del encabezado CNT para seleccionar View Correlated Events (Ver eventos correlacionados).
e. En la ficha nueva, haga clic derecho sobre el ID de alerta correspondiente a una de las alertas GPL ATTACK_RESPONSE id check returned root y seleccione Transcripción. En este ejemplo se utiliza el ID de alerta 5.5848.
f. Revisen las transcripciones correspondientes a todas las alertas. En la última alerta de la ficha probablemente se mostrarán las transacciones entre el actor de la amenaza y el objetivo durante el ataque.
¿Qué sucedió durante el ataque?
El atacante de 209.165.201.17 había obtenido acceso raíz a 209.165.200.235. Se agregó un usuario nuevo myroot sin ninguna contraseña al sistema.
Paso 2: Pasar a Wireshark
a. Seleccionen la alarma que les proporcionó la transcripción en el paso anterior. Hagan clic derecho sobre el ID de la alerta y seleccionen Wireshark.
b. Para ver todos los paquetes ensamblados en una conversación de TCP, hagan clic derecho sobre cualquier paquete y seleccionen Follow TCP Stream (Seguir flujo de TCP).
¿Qué observaron? ¿Qué indican los colores de texto rojo y azul?
La secuencia TCP muestra la transacción entre el agente de amenaza, que aparece en el texto en rojo, y el destino, en el texto en azul. La información obtenida del flujo de TCP es la misma que la de la transcripción.
Salgan de la ventana del flujo de TCP. Cierren Wireshark cuando hayan terminado de revisar la información provista por Wireshark.
Paso 3: Utilizar ELSA para pasar a los archivos de registro de Bro
a. Regresen a Sguil. Haga clic derecho sobre la IP de origen o de destino correspondiente a la misma alerta GPL ATTACK_RESPONSE id check returned root y seleccione Búsqueda de IP con ELSA > DstIP. Introduzcan analyst como nombre de usuario y cyberops como contraseña cuando ELSA se los solicite.
Nota: Si ve el mensaje «Su conexión no es privada», haga clic en AVANZADAS > Proseguir al host local (inseguro) para continuar.
b. Cambien la fecha del campo From (Desde) a la fecha anterior a la fecha que aparece en Sguil. Hagan clic en Submit Query (Enviar consulta).
c. Hagan clic en bro_notice.
d. El resultado indica que 209.165.201.17 estaba realizando un escaneo de puertos en 209.165.200.235. El atacante probablemente encontró vulnerabilidades en 209.165.200.235 para obtener acceso.
e. Si un atacante se ha apoderado de 209.165.200.235, querrán determinar cuál fue el ataque que utilizó y a qué pudo acceder el atacante.
Paso 4: Regresar a Sguil para investigar el ataque
a. Diríjanse a Sguil y hagan clic en la ficha RealTime Events (Eventos en tiempo real). Localicen los eventos ET EXLOIT VSFTPD Backdoor User Login Smiley. Estos eventos son posibles ataques y tuvieron lugar dentro del período de acceso raíz no autorizado.
b. Hagan clic derecho sobre el número que se encuentra debajo del encabezado de CNT y seleccionen View Correlated Events (Ver eventos correlacionados) para ver todos los eventos relacionados. Seleccionen el ID de alerta que comienza con 5. Esta alerta recopiló la información proveniente del sensor en la interfaz seconion-eth1-1.
c. En la ficha nueva con todos los eventos correlacionados, hagan clic derecho sobre el ID de alerta y seleccione Transcript (Transcripción) para ver cada alerta más detalladamente. En la última alerta probablemente se mostrará la transmisión de TCP entre el atacante y la víctima.
d. También pueden hacer clic derecho sobre el ID de alerta y seleccionar Wireshark para revisar y guardar el archivo pcap y el flujo de TCP.
Paso 5: Utilizar ELSA para ver datos exfiltrados
a. Si quieren utilizar ELSA para obtener más información sobre la misma alerta de arriba, hagan clic derecho sobre la dirección IP de origen o sobre la de destino y seleccionen ELSA IP Lookup > DstIP.
b. Cambien la fecha del campo From a una anterior al evento ocurrido, tal como lo indica la marca de hora en Sguil.
c. Hagan clic en bro_ftp para ver los archivos de registro de ELSA relacionados con FTP.
¿Qué archivo se transfirió por FTP a 209.165.200.235? ¿Quién es el dueño de la cuenta que se utilizó para transferir el archivo?
El archivo confidential.txt fue transferido por el usuario analyst.
d. Hagan clic en info para ver las transacciones en el último registro. El campo reply_msg indica que esta es la última entrada correspondiente a la transferencia del archivo confidential.txt. 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).
La transcripción de pcap se traduce utilizando tcpflow, y esta página también proporciona el enlace para acceder al archivo pcap.
e. Para determinar el contenido del archivo afectado, hagan doble clic en el icono del escritorio para abrir ELSA y así abrir una ficha nueva y realizar otra búsqueda.
f. Expandan FTP y hagan clic en FTP Data (Datos de FTP).
g. Cambien la fecha del campo From según sea necesario para incluir el período de interés, y hagan clic en Submit Query.
h. Hagan clic en uno de los enlaces de Información y seleccionen getPcap en el menú desplegable para determinar el contenido del archivo robado.
i. En el resultado se ve el contenido del archivo de nombre confidential.txt que se transfirió al servidor FTP.
Paso 6: Limpieza
Apaguen la VM cuando hayan terminado.
Reflexión
En esta práctica de laboratorio han revisado los archivos de registro como analistas especializados en ciberseguridad. Ahora resuman lo que aprendieron.
A partir de los archivos de registro de Sguil y ELSA se determinó que un atacante (209.165.201.17) aprovechó la vulnerabilidad vsftpd para obtener acceso raíz a 209.165.200.235. Utilizando el acceso raíz que obtuvo en el ataque, el delincuente agregó un usuario raíz nuevo myroot para obtener acceso raíz en el futuro. El atacante se apoderó del usuario analyst para obtener acceso a una estación de trabajo interna: 192.168.0.11. Utilizando la cuenta analyst, el atacante logró obtener acceso al archivo de nombre confidential.txt y lo transfirió por FTP a 209.165.200.235, dirección en la que tiene acceso remoto para recuperar el archivo.