TAREA 4 12.4.1.2 CRISTIAN RICAURTE-comprimido

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 19

PASO 6 ACTIVIDAD COLABORATIVA 3

STUDENT NAME
CRISTIAN ANDRES RICAURTE RINCON
GROUP 2150521_36
IDENTIFICATION: 1006558648

TEACHER:

JUAN ESTEBAN TAPIAS

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA - UNAD

ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA

ACCESO A LA WAN

26 DE NOVIEMBRE DE 2021

ACACIAS – META
PRÁCTICA DE LABORATORIO: HOST COMPROMETIDO AISLADO UTILIZANDO
EL MÉTODO DE 5 COMPONENTES (5-TUPLE)

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 analista y raíz 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?

RESPUESTA:

El atacante de 209.165.201.17 (Kali Linux) había obtenido acceso de root a 209.165.200.235


(Metasploitable). Se agregó al sistema un nuevo usuario myroot sin contraseña.

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?

RESPUESTA:

El flujo de TCP muestra la transacción entre el actor de la amenaza que se muestra en texto
rojo y el objetivo en texto azul. La información del flujo de TCP es la misma que en la
transcripción

c. 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?

RESPUESTA:

El archivo confidencial.txt fue transferido por el analista de usuarios.

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.

RESPUESTA:

A partir de los registros de Sguil y ELSA, se determinó que un atacante en 209.165.201.17


aprovechó la vulnerabilidad vsftpd para obtener acceso de root a 209.165.200.235. Al utilizar el
acceso de root obtenido del ataque, el atacante había agregado un nuevo usuario root myroot para
el futuro acceso de root. El atacante comprometió al analista de usuarios para obtener acceso a
una estación de trabajo interna, 192.168.0.11. Al usar la cuenta de analista, el atacante pudo
obtener acceso al archivo denominado confidencial.txt y transferir el archivo mediante FTP a
209.165.200.235, donde el atacante tiene acceso remoto para recuperar el archivo.
CONCLUSIONES

Con este laboratorio, se utilizaron vulnerabilidades para acceder a información no autorizada y


revisaron archivos de registro como analistas profesionales de seguridad cibernética. Ahora resuma
lo que aprendió. La vulnerabilidad no resuelta del sistema remoto se utilizó para acceder y controlarlo
a través de la asignación de roles de raíz,

También podría gustarte