Advent of Cyber día 2

La alerta es el punto de partida, no la conclusión. En este ejercicio seguimos la secuencia de eventos para explicar por qué algo parece malicioso y qué evidencia falta. Primero los logs, luego el veredicto.

Contexto histórico: recorrido de Advent of Cyber 2024. Las capturas y respuestas corresponden al ejercicio original.

Advent of Cyber día 1

Qué aplicamos:

• Herramientas SIEM con elastic SIEM
• Análisis SOC (Security Operations Center)
• Análisis de Logs

Objetivos:

• Entender el uso de las herramientas SIEM
• Investigar y lograr diferenciar TRUE POSITIVE y FALSE POSITIVE

---

Comienzo

Los analistas SOC se encargan de monitorear y analizar eventos de seguridad en redes y sistemas, además de responder a las mismas. Lo que tenemos que hacer en este desafío es analizar logs de un SIEM e investigar si lo que estamos viendo son true positive (amenazas reales) o false positives (alertas que saltaron pero que no eran realmente amenazas).

Lanzamos la máquina y nos conectamos a la url con las credenciales que nos proporcionan. Nos vamos a Discover y nos encontramos con lo siguiente:

Aún no hemos realizado ninguna búsqueda ni filtro. Para empezar, según la narrativa saltó una alarma el 1ro de Diciembre del 2024 entre 0900 y 0930. En el calendario, en la barra de búsqueda debemos seleccionar el time-frame. Le damos con absoluto e insertamos las fechas y horas desde y hasta cuando.

En teoría, podríamos leer los logs así como están pero son poco amigables. Afortunadamente podemos agregar filtros, categorías y columnas para mejor organizar la información. Según la narrativa de la práctica estamos buscando eventos relacionados a Powershell, por lo tanto nos sirve agregar las siguientes columnas:

• El nombre de host donde se corrió el comando. host.hostname
• El usuario que lo ejecutó. user.name
• Agregamos event.category para asegurar que estamos viendo la categoría correcta
• Para saber el comando agregamos process.command_line
• Para revisar el resultado declarado por el productor del evento, agregamos event.outcome; success no demuestra por sí solo que toda la operación de negocio o el script terminó bien

Ahora podemos verlo más organizado. Lo primero que podemos ver es que se corrió un comando codificado, que fue efectivo, que se corrió en distintas máquinas y que hubieron eventos de autenticación cada vez que se fue a correr el comando. Algo que podríamos hacer es filtrar por IP para ver si hay algo de información útil: Vamos a la izquierda a los filtros, agregamos source.ip, vamos al evento de autenticación, nos posicionamos sobre el símbolo +, con eso logramos que se filtre por esta categoría. No obtenemos nada útil, sólo podemos ver que son IP privadas locales. Dado que no nos sirvió de mucho que digamos, vamos a quitar el filtro.

Qué hacer ahora?

Las autenticaciones podrían venir desde mucho antes, por lo tanto vamos a aumentar el timeframe a un par de días antes y expandir las horas. Esto ahora nos arroja 6814 actividades con un salto inmenso al final, claramente sucede algo. Vamos a aplicar los siguientes filtros:

• user.name en service_admin
• source.ip con la ip local 10.0.11.11

Con eso reducimos un poco la cantidad de hits, pero aún necesitamos más información.

Agregamos un filtro para mostrar los resultados que NO incluyan esa ip. Con ello notamos que hubieron miles de intentos fallidos antes de lograr conectarse. Posteriormente podemos seguir indagando a través de los filtros. Podemos eliminar el filtro de ip y probar sólamente verificando las alertas de autenticación. A la larga, todo apuntaría a un ataque de fuerza bruta.

Y el script?

Si recordamos el script que se ejecutó, el comando estaba codificado y no se revisó.

`C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -EncodedCommand SQBuAHMAdABhAGwAbAAtAFcAaQBuAGQAbwB3AHMAVQBwAGQAYQB0AGUAIAAtAEEAYwBjAGUAcAB0AEEAbABsACAALQBBAHUAdABvAFIAZQBiAG8AbwB0AA==`

Generalmente estas codificaciones son realizadas en Base64, por lo que vamos a CyberChef para decodificarla. CyberChef procesa normalmente del lado del navegador y también puede usarse localmente. Estar en un laboratorio no autoriza a divulgar cualquier dato; hay que distinguir el tratamiento local de compartir enlaces o realizar operaciones con red. Repositorio oficial.

En CyberChef agregamos las siguientes "recetas". Le indicamos que viene de Base64 y que realice la decodificación del texto. Además le indicamos que es UTF-16LE(1200) que es la codificación que usa Powershell

Con eso obtenemos el resultado: La decodificación de la cadena da Install-WindowsUpdate -AcceptAll -AutoReboot. Se comprobó como texto Base64/UTF-16LE, sin ejecutarlo. Es el nombre de un comando que requiere su implementación/módulo; el texto no demuestra que una actualización se completó.

---

Lo que sucedió según la narrativa es que:

• Las credenciales que se utilizaban para actualizar las máquinas de windows estaban obsoletas.
• Alguien realizó fuerza bruta para acceder y arreglar las credenciales.
• La evidencia está en que cada vez que se ejecutó el comando, previamente se autenticó correctamente.

Con esto finalmente podemos responder las preguntas:

• ¿Cuál es el nombre de la cuenta causando los logins fallidos?
  • Esto podemos obtenerlo con los filtros mencionados previamente
• ¿Cuantos intentos fallidos de logon?
  • Esto podemos obtenerlo también con los filtros, filtrando por fallidos.
• ¿Cuál es la dirección IP de Glitch?
  • Esto podemos obtenerlo cuando filtramos las IP y notamos la IP distinta.
• ¿Cuándo logró Glitch loguearse a ADM-01?
  • Nuevamente los filtros nos ayudan a esto, debemos buscar el primer intento evento success y agregando la máquina ADM-01 junto a la IP de Glitch.
• ¿Cuál es el comando decodificado?
  • Lo obtenemos a través de cyberchef, aplicando decodificación de base64 (UTF-16LE(1200))

Hemos resuelto el desafío del día 2.

Continuamos con el Advent of Cyber día 3

Referencia de campos: Elastic ECS, event.outcome. La causa y el actor que propone la narrativa se conservan como resultado histórico del desafío, no como atribución independiente.

+----------------------------------------+
| Floure &                               |
| Tachibana's guild                      |
| [Hikari · Nozomi]                      |
| SEAL: sha256/12: 51b3beee0a1c          |
| STATUS: LITURGY_IN_PROGRESS            |
+----------------------------------------+