BOTS Taedonggang APT - Parte 1

Las simulaciones de Boss of the SOC (BOTS) son entornos gamificados que nos permiten fortalecer nuestras habilidades como Blue Team, aunque en escenarios como Taedonggang APT, también exploramos técnicas propias del Red Team, especialmente en las etapas iniciales de una intrusión.

En este escenario, nos enfrentamos a una campaña simulada de un actor avanzado persistente (APT), donde debemos identificar y analizar los vectores de acceso inicial, así como realizar un profundo reconocimiento de la infraestructura comprometida. Aquí no buscamos tomar control total de una máquina, sino entender cómo lo haría un atacante real y cómo podríamos detectarlo.

Durante el reto, ponemos en práctica técnicas como:

• Análisis de logs para detectar patrones sospechosos
• Revisión de artefactos de acceso remoto como credenciales o herramientas de administración
• Identificación de TTPs (Técnicas, Tácticas y Procedimientos) asociadas a grupos APT
• Reconstrucción de la línea de tiempo del ataque para entender su progresión

Este tipo de laboratorios nos ayuda a afinar el ojo analítico, comprender el comportamiento adversario y fortalecer nuestras capacidades de detección temprana. En Taedonggang APT, cada pista cuenta, y cada hallazgo nos acerca más a entender cómo se infiltran los atacantes… y cómo podemos detenerlos.

Primer escenario: Acceso Inicial

La primera tarea está en investigar el acceso inicial de un atacate; para los que no estén familiarizados en el proceso, primero, no te puedes lanzar como si nada a investigar logs a diestra y siniestra; lo primero que ocupas es una hipótesis y luego, en investigar alrededor de está hipótesis.

Entonces, partimos pensando ¿Cuál es la vulnerabilidad más utilizada actualmente para alcanzar el acceso inicial?, la respuesta, claramente, sería el phishing así que empecemos a plantear preguntas: ¿Cuál es la forma más común de entregar phishing? ¿Nuestras fuentes de logs cubren algo así? ¿Qué tipos de adjuntos podríamos buscar?.

Para empezar entonces, investiguemos cuáles son los tipos de datos que tenemos y para averiguarlo tendremos varias alternativas:

index="*" | stats count by sourcetype

Esta búsqueda mostrará todos los sourcetypes de todos los index

| metadata type=sourcetypes index="*" | eval firstTime=strftime(firstTime,"%Y-%m-%d %H-%M-%S") | eval lastTime=strftime(lastTime, "%Y-%m%d %H-%M-%S") | eval recentTime=strftime(recentTime, "%Y-%m-%d %H-%M-%S")

Esta búsqueda mostrará todos los sourcetypes de todos los index con su rango de fechas

Claro, que para trabajar, nos tendrán que decir o al menos, saber, con qué index estaremos trabajando y también, si el incidente a investigar tiene otra fecha en específico o si tenemos que estar trabajando con datos en tiempo real, en cualquier caso, mientras nos den información, tenemos que aprovecharla para nuestro análisis.

• Agosto 2017
• index: botsv2

| metadata type=sourcetypes index="botsv2" | eval firstTime=strftime(firstTime,"%Y-%m-%d %H-%M-%S") | eval lastTime=strftime(lastTime, "%Y-%m%d %H-%M-%S") | eval recentTime=strftime(recentTime, "%Y-%m-%d %H-%M-%S")

Ajustamos nuestro index y también filtramos DESDE 01/Agosto/2017

Y pronto veremos cuántas fuentes disponibles tenemos:

No debe asustarnos el número, asústate cuando no tengas la fuente que necesites hahaha

Pronto visualizamos una fuente que nos sirve directamente en nuestra hipótesis: El protocolo SMTP (Simple Mail Transfer Protocol) que cubriría mails maliciosos.

Ahora, podemos filtrar todos los eventos desde esta fuente:

index=botsv2 sourcetype="stream:smtp"

Ahora, lo importante es familiarizarnos con el formato y los campos que tiene cada log; no hace falta ver cada uno de los logs, sino intentar imaginar qué campos cubre o no nuestra fuente; para tirar un poco a la suerte, podemos intentar buscar algo como ‘attachment’ para buscar algún contenido/documento adjunto que haya sido enviado por este medio; entonces accedemos dando clic…

Y buscamos

Añadimos entonces el campo a la búsqueda:

index=botsv2 sourcetype="stream:smtp"  "attach_filename{}"="*"

Lo que nos mostrará sólo los correos que hayan tenido un adjunto en él. Con los primeros resultados, podemos afinar y presentar mejor los resultados para que sea más digerible:

index=botsv2 sourcetype="stream:smtp" "attach_filename{}"="*" | table sender_email, receiver_email,  subject,  attach_filename{},  attach_content_md5_hash{}, date

Esta búsqueda mostrará en una tabla los campos del remitente, destinatario, asunto, el nombre del adjunto, su md5 y la fecha

En los resultados, tenemos varios adjuntos interesantes; en primera, los 4 archivos zip y luego los 4 txt exactamente a los mismos destinatarios:

La sospecha puede aumentar bastante, ya que la diferencia de las fechas y los adjuntos sujieren un comportamiento sospechoso, podemos examinar los mensajes para aclarar dudas:

Parece un motivo muy sospechoso para eviar un comprimido de esta manera, para confirmar continuemos con los que tienen el txt, que nos indica un mensaje en base64:

Este mensaje parece ser generado por la protección del correo electrónico; la alarma de un Phishing (Spearphishing) se confirma cuando notas que el archivo que generó la alerta tiene el mismo nombre que el comprimido enviado tiempo después, por el mismo remitente.

Primer escenario, Segunda parte: Ejecución

Una vez confirmado la existencia de un archivo malicioso, lo que sigue es investigar qué acciones se realizaron en los equipos infectados; ¿Qué fuentes de logs pueden cubrir ejecuciones? ¿Deberíamos buscar eventos antes o después del spearphishing? ¿Logró ejecutarse en el equipo? ¿Qué otros indicadores tenemos?

Estas preguntas nos guiarán en nuestra hipótesis de ejecución de comandos, así que empecemos por investigar qué equipos o usuarios, recibieron el archivo; la manera fácil, es buscar la extensión en el sysmon (que, está disponible en nuestras fuentes) y claro, filtrando después del spearphishing

index="botsv2" sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" zip | sort + UtcTime

Esta búsqueda busca en el Operational en busca del string ‘zip’, ordenando por los menos recientes

Con esta búsqueda, podemos notar que ya encontramos algunas ejecuciones:

Entonces aprovechamos este log para enriquecer la búsqueda; entonces veamos si fue el único host afectado:

index="botsv2" sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" invoice.zip | sort + UtcTime | table host, TargetFilename

Ya confirmado, podemos investigar las acciones del archivo sobre el host:

index="botsv2" sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" invoice.zip  host="wrk-btun" | sort + UtcTime 

Esto nos está indicando que el usuario abrió el archivo con Word, lo que puede seguir de aquí es ejecución de comandos tanto por powershell como por cmd, iniciemos con powershell:

index="botsv2" sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" Computer="wrk-btun.frothly.local" Image="C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" | sort + UtcTime

Image es el campo del programa ejecutado relacionado con el log en la computadora afectada

El primer resultado devuelto va a saltar a la vista, un poco por el tamaño pero especialmente el -nop -w 1 -enc; que indica: Ejecutar sin cargar el perfil del usuario, de forma oculta el siguiente script en base64 (Todo indicando evasión) entonces, investigamos el payload con la siguiente receta de Cyberchef:

Que hace algunas cosas:

1. Hace un bypass del AMSI (evasión del host)
2. Desactiva Expect100Continue (evasión del firewall)
3. Configura el WebClient para simular un Internet Explorer
4. Configura el Proxy del sistema utilizando las credenciales del usuario actual
5. Añade una clave de descifrado
6. Añade una cookie y se conecta al C2
7. Extrae el IV y descifra el payload

Ya confirmado nuestra hipótesis, también podemos correlacionar los procesos para saber qué otras acciones o programas se ejecutaron:

index="botsv2" sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" Computer="wrk-btun.frothly.local" user="FROTHLY\\billy.tun" | sort + UtcTime | table _time, process, process_id , parent_process, parent_process_id, CommandLine

Esto revela los logs ejecutados por el usuario y en el equipo infectado, mostrando el programa ejecutado mostrando la linea de comandos

Para tener una forma de trazabilidad clara, qué acciones y programas se ejecutaron después para crear todo el árbol de procesos:

Segundo escenario: Reconocimiento

Ahora, si recordamos el concepto de la Cyber Kill Chain, el reconocimiento es algo complicado, pero no imposible, sólo hay que tener una hipótesis clara sabiendo lo que queremos buscar y aplicar filtrado poco a poco

Entonces, para aplicar el filtrado, necesitamos un campo que sea algo general para no perder de vista algún evento relevante

Lo que podemos plantear es con el User-Agent es si hay algo anómalo, el si ese UA hace peticiones a ciertos archivos y tratar de hacer el seguimiento a sus acciones.

Entonces empezamos a buscar la fuente relevante (stream:http) para ver cómo está organizado:

index="botsv2" sourcetype="stream:http"

Ya sabiendo que es nuestra fuente relevante, podemos empezar a organizar para filtrar

index="botsv2" sourcetype="stream:http" | stats count by http_user_agent | sort - count

La busqueda nos mostrará una tabla con los UA más comunes, pero bajando podremos encontrarnos con algunos interesantes como los siguientes

Dejando de ladito a los intentos de ejecución de comandos, debemos observar el NaenaraBrowser; Naenara Browser es un navegador de Corea del Norte, esto puede ser un indicador que pueda llevarnos a algo, especialmente porque no es muy común. Entonces bajo sospecha del User Agent, hacemos OSINT a la IP, para verla, podemos ver el campo ` src_ip` en el log que corresponda (85.203.47.86).

Buscando con iplocation.net encontramos la ubicación del ISP de la IP y no es Corea del Norte.

Buscando ahora la organización propietaria de la IP, podemos encontrar también que es de un servicio de infraestructura de TI, incluyendo VPS.

Extracción de archivos públicos

Bien, ahora sigue hacer la traza de las acciones realizadas, una búsqueda sencilla puede ser buscar el tipo de contenido (para tener una visión general y rápida de lo que buscaba), el uri_path para saber exactamente qué directorio está solicitando, el código HTTP (para saber si fue exitoso o no) y el timestamp (para saber cuándo lo hizo):

index="botsv2" sourcetype="stream:http" http_user_agent="Mozilla/5.0 (X11; U; Linux i686; ko-KP; rv: 19.1br) Gecko/20130508 Fedora/1.9.1-2.5.rs3.0 NaenaraBrowser/3.5b4" | table  http_content_type, uri_path, status, timestamp

Donde una de las entradas tiene un nombre alarmante:

Lo que sigue es saber ¿qué contenía este archivo?, ¿cuántos son los afectados? y volver a armar nuestras hipótesis desde aquí como parte del proceso defensivo.

Tercer Escenario: Preparación Remota de Datos

La siguiente tarea va con la hipótesis de que los datos fueron preparados para la exfiltración, específicamente, la subtécnica reconoce que un atacante, para facilitar la tarea del robo/salida de datos, debe prepararse en algún lugar centralizado para facilitar las tareas posteriores; bajo este criterio, podemos preaparar nuestras preguntas ¿Qué fuentes nos pueden indicar una preaparación de datos? ¿Qué flujo de datos puede indicar una preparación de los datos? ¿Qué tipos de datos podemos imaginarnos que están preparándose? ¿Hay actividad posterior indicando el exfiltrado de los datos? ¿Qué cuentas de usuarios pudieron usarse para la preparación?

Primero, veamos qué fuentes de logs capturaron movimientos de archivos:

index="botsv2" (docx OR doc OR pdf OR xls OR xlsx) | stats count by source

Estamos buscando en los sources la cantidad de logs que mencionen algunas extensiones de archivos de oficina comunes

Esta búsqueda nos da la idea de qué logs utilizar:

SMB puede ser un excelente punto de partida ya que es de los protocolos más comunes a la hora de compartir archivos en entornos grandes junto con FTP, probemos primero SMB.

Logs SMB

Iniciamos con una búsqueda para saber qué host fue el que más actividad tuvo en cuanto a operaciones con SMB:

index="botsv2" source="stream:smb" (docx OR doc OR pdf OR xls OR xlsx) | stats count by src_ip, dest_ip | sort - count

Desde aquí podemos ver el principal cliente (más de 1700 peticiones en muy poco tiempo)

Claramente, esto indica una alarma de la gran cantidad de archivos transferidos; para ver qué archivos se han movido, puedes utilizar una query más descriptiva añadiendo algunos campos extras del tipo de log stream:smb

Primero veamos cómo se registran las operaciones en el log:

index="botsv2" source="stream:smb" src_ip=10.0.2.107 | stats count by command

Esto nos muestra los varios valores en el campo command

Al que debemos poner atención es smb2 create que se genera cuando se crea, abre o accede a un archivo en el servidor SMB:

index="botsv2" source="stream:smb" src_ip=10.0.2.107  command="smb2 create" filename!="*Zone.Identifier" | table filename, _time | dedup filename

Estamos filtrando el Zone.Identifier ya que esta extensión la genera el cliente windows cuando se descarga un archivo de una fuente externa.

Esta búsqueda refleja qué archivos fueron movidos por el atacante.

De momento, el atacante ha movido los archivos, pero debemos investigar ahora la transferencia por una posible filtración de datos.

Logs FTP

El siguiente protocolo es FTP, para ello, utilizamos el source stream:ftp (Hay más formas de filtrar datos pero es un buen punto de partida)

index="botsv2" source="stream:ftp" src_ip=10.0.2.107

Primero correlacionamos la IP con el uso del protocolo, aprovechando para conocer la forma del log

Ahora sabiendo la lógica del log, podemos modificarlo un poco para ver con qué servidor se está conectando:

index="botsv2" source="stream:ftp" src_ip=10.0.2.107 | stats count by dest_ip, src_ip

Con esta búsqueda podrás saber cuántos logs se generaron correlacionando su comunicación; Con esto, confirmamos el filtrado de los archivos.

Agradecimiento

Si lees esto, gracias por llegar hasta aquí!, si existen dudas, comentarios y correcciones (que son más que bienvenidas) contáctame con confianza, que siempre he dicho que la ciberseguridad es esfuerzo conjunto.

En caso que no los vea, buenos días, buenas tardes y buenas noches. Happy Hacking!.