Ransomware ate my network (V)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior ya habíamos terminado el análisis forense del incidente, por lo que Ángela ya tenía una visión global de todo lo que había ocurrido. Los timelines son una herramienta de análisis sensacional para poder entender lo ocurrido en un incidente, así que construimos una (con las horas en UTC, no perdamos las buenas costumbres):

  • 4/Nov: Los atacantes envían los correos con enlaces maliciosos a personal de la FFP.
  • 9/Nov – 11:37h – dolores.jolgorio abre el correo, descarga y ejecuta el .doc con la macro maliciosa.
  • 11:38h – El equipo se infecta con un agente de Meterpreter.
  • 11:41h – Los atacantes ejecutan diversos comandos para reconocer el sistema.
  • 11:46h – Los atacantes “revenden” el acceso al segundo grupo, cediendo el control con un agente de Empire.
  • 12:01 – Los atacantes elevan privilegios con un exploit de la vulnerabilidad CVE-2020-0787.
  • Entre las 12:01 y las 12:37h: Vuelcan hashes con la funcionalidad Powerdump de Empire.
  • 12:37h – Lanzan SharpHound e identifican W10-PC3 como equipo con una sesión iniciada de administrador de dominio.
  • 13:16h – Con los permisos de administrador local, copian el stager de Empire a W10-PC3 y lo ejecutan con PsExec.
  • Entre las 13:16 y las 13:30h – Obtienen el hash NTLM de la cuenta dom.adm con Mimikatz.
  • 13:51h – Montan el pivot SSH-RDP y acceden al DC con el hash NTLM de la cuenta dom.adm.
  • 13:55h – Copian el fichero temp.zip con las GPO y scripts de Powershell.
  • 13:57h – Despliegan la GPO “All in One”, que erosiona severamente la seguridad de los equipos del dominio.
  • 15:08h – Despliegan la GPO “Scheduler”, que copia el ransomware a los equipos y deja programada una tarea para su ejecución a las 17:15h.
  • 15:13h – Lanzamiento de un agente de Empire.
  • 15:30h – Saltan las alertas en GLORIA.
[Read more…]

Ransomware ate my network (IV)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

[Nota del editor: Pinchando en muchas imágenes –aquellas cuyo detalle no se ve del todo con el tamaño de la página principal– se muestra una versión ampliada]


En el artículo anterior vimos cómo Ángela había deducido que los atacantes habían entrado en el equipo empleado para conectarse al DC desde otro equipo empleando la herramienta PsExec. Dispuesta a encontrar el PsExec, Ángela empieza convirtiendo a .csv la MFT extraída por CyLR con mftdump.exe, y buscando por actividad alrededor de la la hora en la que vio la conexión en el otro equipo (sobre las 14:16h, 13:16h en UTC que es lo que nos muestra la MFT).

No hay un objetivo claro, pero ese Prefetch de stalin.exe parece sospechoso (recordemos que los Prefetch se crean la primera vez que se ejecuta el software, con un retraso de unos pocos segundos).

[Read more…]

Ransomware ate my network (III)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior la investigación se había quedado con el equipo con la IP 10.11.2.14 como origen de las conexiones al DC (y que tenía tanto conexiones con el C2 101.143.122.216 como el antivirus desactivado de forma previa al ataque generalizado).

Dado que estamos hablando de conexiones y que disponemos de la memoria RAM, lo primero que hace Ángela es emplear el plugin netscan de Volatility para sacar las conexiones de red (el perfil de memoria es Win10x64_17134) y confirmar las conexiones con el C2:

Netscan devuelve a su vez unos cuantos resultados adicionales:

¿Una conexión a un SSH remoto?

¿Y qué hace este equipo prestando un servicio en el puerto 443/TCP? ¿Se ha vuelto loco? Está claro que tenemos que profundizar en estas conexiones saber qué hay detrás de ellas. Ángela decide revisar los logs de Sysmon, en los que tendrían que aparecer las conexiones de red… pero parece que la FFP no aplicó correctamente la configuración de Sysmon estándar del MINAF, por lo que no se están recogiendo esos datos (grrrrrrr).

[Read more…]

Ransomware ate my network (II)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

En el artículo anterior vimos cómo el MINAF había evitado por los pelos un ataque de ransomware, pero nos quedaban muchísimas preguntas por resolver.  En primer lugar, averiguar la identidad del grupo de ransomware que había afectado al MINAF. 

Para ello Ángela convierte la MFT del DC con mftdump.exe y realiza una búsqueda rápida de los ficheros v2.exe y v2c.exe, que parecían a priori los encargados de desplegar el ransomware. Da en el clavo porque encuentra los ficheros en la carpeta c:\temp\scheduler:

Rápidamente calcula sus hashes:

5994df288813a7d9588299c301a8de13479e3ffb630c49308335f20515ffdf57  v2c.exe
b2a304e508415d96f417ed50d26e0b987b7cbd9a77bb345ea48e803b5a7afb49 v2.exe
ffa8722a09829acd7ef8743688947f6ccb58d2ef v2c.exe
7320b34c07206fcaf1319d6ce9bef2b29648a151 v2.exe
eddc0e293b0f0ee90bab106f073a41c9 v2c.exe
91438699bed008be9405995f0a158254 v2.exe

Lo siguiente es comprobar si son conocidos. VirusTotal le da una respuesta rápida:

[Read more…]

Ransomware ate my network (I)

Una breve explicación de esta serie con algunas notas aclaratorias se puede leer al comienzo del primer artículo.
Entradas de la serie:
=> Primera parte
=> Segunda parte
=> Tercera parte
=> Cuarta parte
=> Quinta parte

Nota 1: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XIV Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación.

Nota 2: Estos posts desgranan un taller de análisis forense englobado dentro de la respuesta ante un incidente. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que sean fáciles de entender. Y como todo taller práctico, se puede aprovechar de varias maneras: podéis descargar desde LORETO las evidencias ya trabajadas para poder seguir el caso paso por paso, podéis descargaros las evidencias en bruto para hacer vuestra propia investigación … o podéis jugar al CTF DFIR que hemos preparado y que os irá desgranando el caso a medida que vayáis respondiendo a los diversos retos.


Hay pocos meses buenos para la ciberseguridad en una Administración Pública, y noviembre no es uno de ellos: hay que tener cerrados los proyectos, realizar informes de estado, asegurarse de que todo el presupuesto está ejecutado (y justificado con las facturas correspondientes).

Ángela de la Guarda, CISO del MINAF (Ministerio de la Alegría y la Felicidad) no ha tenido un año especialmente alegre: la pandemia obligó a desplegar a marchas forzadas teletrabajo para buena parte del personal, lo que causó una sobrecarga importante sobre todo el personal TIC … y más si cabe sobre su ella y su equipo, responsables de garantizar la seguridad de todos los sistemas.

Para más inri, en la consabida reestructuración con cada cambio de gobierno, al MINAF se le ha encargado la misión de “unificar todos los organismos estatales con competencias sobre la alegría y la felicidad”. Esto ha supuesto la absorción de varios entes de diverso tamaño, entre los que destaca la FFP (Federación de Festejos Patronales, encargada de la gestión de todas las fiestas de pueblo de España). La FFP tiene, por así decirlo … una visión más bien relajada de la ciberseguridad, lo que está haciendo que la asimilación haya sido altamente conflictiva. Al final las altas esferas han mandado, y el MINAF ha absorbido a la FFP “de aquellas maneras”.

Son las 17.00h, y Ángela está revisando correos para terminar el primero de una semana llena de informes y poder irse a su casa, cuando Salvador Bendito (analista de seguridad del MINAF) la llama al móvil: “Jefa, tenemos un problema muy serio. Ha saltado uno de los canarios: estamos perdiendo a los porteros. A todos ellos”.

[Read more…]

Bastionado de sistemas contra ataques ransomware

En los tiempos que corren, la ciberseguridad parece haber quedado en un segundo plano (y no sin razón, hay mucha gente que tiene otras preocupaciones más acuciantes).

Sin embargo, los cibercriminales no descansan. Y en estos momentos en los que todo aquel que puede está en su casa teletrabajando (¡bien hecho!), en muchos casos a marchas forzadas, somos especialmente vulnerables a ciberataques (un ransomware, por ejemplo, podría ser desastroso).

[Read more…]

Vientos remotos, tempestades locales (V)

[Nota: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XIII Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación].

[Nota 2: Estos posts desgranan un taller de análisis forense englobado dentro de la respuesta ante un incidente. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que sean fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: el CCN-CERT está alojando en LORETO todo el material, que podéis descargar desde aquí. Tenéis tanto las evidencias en bruto (si queréis primero intentar encontrar el bicho por vuestra cuenta sin leer nada de la solución) como una guía paso a paso con todas las herramientas y evidencias necesarias en cada paso].


Al día siguiente, con medio litro de café en el cuerpo, Ángela queda en el MINAF con Salvador y le pone al corriente de todo lo sucedido. A grandes rasgos, su teoría de lo sucedido es la siguiente:

  1. Los atacantes han descubierto el servidor web WEBSERVER, han visto que era vulnerable a BlueeKeep y han explotado la vulnerabilidad para lograr acceso al sistema.
  2. Una vez dentro, han volcado las credenciales del sistema con procdump, y obtenido las de salvador.bendito (admin del dominio)
  3. Han dejado una webshell como acceso secundario, y han entrado en el equipo de salvador.bendito (ADMINPC1)
  4. Se ha realizado un reconocimiento de la red, y han encontrado CHITONSRV.
  5. Han intentado acceder a CHITONSRV con las credenciales de admin de domino sin éxito (CHITONSRV está fuera de dominio, con un admin local distinto)
  6. Los atacantes han desplegado el keylogger Refog, y esperado a que Salvador Bendito entrara en CHITONSRV
  7. Una vez Salvador Bendito ha entrado en CHITONSRV (y su contraseña queda capturada en Refog), los atacantes entran de nuevo por Escritorio Remoto siguiendo la cadena WEBSERVERà ADMINPC1à CHITONSRV, y roban la carpeta Secreto.
  8. Se instala TeamViewer en el equipo ADMINPC1, y se emplea para exfiltrar los datos.

[Read more…]

Vientos remotos, tempestades locales (IV)

[Nota: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XIII Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación].

[Nota 2: Estos posts desgranan un taller de análisis forense englobado dentro de la respuesta ante un incidente. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que sean fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: el CCN-CERT está alojando en LORETO todo el material, que podéis descargar desde aquí. Tenéis tanto las evidencias en bruto (si queréis primero intentar encontrar el bicho por vuestra cuenta sin leer nada de la solución) como una guía paso a paso con todas las herramientas y evidencias necesarias en cada paso].


En el artículo anterior habíamos dejado a Ángela buscando la localización de WEBSERVER para poder extraer evidencias que le permitieran comprender el alcance de la intrusión.

El nombre no le es familiar, así que puede ser algún servidor nuevo que haya sido puesto en producción recientemente. Ángela busca en la herramienta de inventario sin éxito. Revisa su hoja Excel con los equipos de la DMZ sin encontrar WEBSERVER. Manda un mensaje al área de Sistemas dentro del programa de mensajería corporativa interna … y está a punto de meterse en el cortafuegos perimetral a revisar a mano una a una las reglas cuando Beneplácito Seguro (uno de los administradores de red del MINAF), le dice que conoce ese servidor, y le cuenta la historia detrás del mismo.

[Read more…]

Vientos remotos, tempestades locales (III)

[Nota: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XIII Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación].

[Nota 2: Estos posts desgranan un taller de análisis forense englobado dentro de la respuesta ante un incidente. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que sean fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: el CCN-CERT está alojando en LORETO todo el material, que podéis descargar desde aquí. Tenéis tanto las evidencias en bruto (si queréis primero intentar encontrar el bicho por vuestra cuenta sin leer nada de la solución) como una guía paso a paso con todas las herramientas y evidencias necesarias en cada paso].


En el artículo anterior dejamos a Ángela con la sensación de que “algo no encajaba”, que tenía que investigar más a fondo el equipo de Salvador Bendito para estar totalmente segura de su culpabilidad.

Paso 2.4: Prefetch

Ángela decide que la mejor forma de saber qué es lo que ha pasado en el equipo es revisar todos los programas ejecutados. Aunque Windows 10 tiene funcionalidades nuevas para ello como el BAM (Background Activity Monitoring) o el AmCache, si todavía tenemos Prefetch es la primera opción a tener en cuenta.

[Read more…]

Vientos remotos, tempestades locales (II)

[Nota: Esta serie de posts es una narración de un análisis forense de un caso práctico de respuesta ante incidentes totalmente ficticio (pero contada, esperamos, de forma didáctica y con gracia y salero). Si queréis una versión con la misma dosis técnica pero con menos narrativa, podéis consultar el vídeo de la charla que el autor dio en las XIII Jornadas STIC del CCN-CERT, o echar un ojo las slides de la presentación].

[Nota 2: Estos posts desgranan un taller de análisis forense englobado dentro de la respuesta ante un incidente. Habrá algunas cosas que se podrían hacer de manera más eficiente y elegante, pero la idea era hacerlas de forma sencilla para que sean fáciles de entender. Y como todo buen taller práctico, se puede seguir paso a paso: el CCN-CERT está alojando en LORETO todo el material, que podéis descargar desde aquí. Tenéis tanto las evidencias en bruto (si queréis primero intentar encontrar el bicho por vuestra cuenta sin leer nada de la solución) como una guía paso a paso con todas las herramientas y evidencias necesarias en cada paso].


En el artículo anterior comprobamos que, al parecer, se habían producido algunos accesos altamente irregulares desde el equipo de Salvador Bendito, el administrador de sistemas senior (y única persona además de los altos cargos del MINAF que tenía acceso a CHITONSRV).

La cuestión es bastante delicada: Salvador Bendito lleva 7 años como funcionario del MINAF, con un comportamiento intachable y habiendo sido parte fundamental en la respuesta a otros incidentes (como el del malware fileless del año pasado). Sin embargo, ante la más mínima posibilidad de que él haya sido el culpable, se impone seguir un riguroso procedimiento que ofrezca todas las garantías.

[Read more…]