[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].
La semana no ha sido especialmente agradable para Ángela de la Guarda, CISO del MINAF (Ministerio de la Alegría y la Felicidad). A la media docena de reuniones para dar el último empujón a la implantación del ENS (Esquema Nacional de Seguridad) en el MINAF se ha sumado el papeleo de la renovación de varios contratos del área… y la crisis de la pérdida de la alta disponibilidad de uno de los sistemas críticos de la subdirección TIC del MINAF: se ha roto una de las dos máquinas de café (lo que significa una sola máquina para alrededor de 80 personas; imagina el aumento de la latencia y los timeout que ello implica).
Menos mal que ya estamos a viernes, y el fin de semana se acerca con un spa, la serie Fleabag y un rato de cacharreo con la Raspberry Pi 4… o esos eran los planes de Ángela hasta que recibe una llamada urgente del CCN-CERT (el por qué estas llamadas son siempre los viernes a las 14.15h es algo que solo $deity sabe, pero casi siempre son a estas horas).
El CCN-CERT le pasa una URL de un dominio .onion, y Ángela la abre con su Tor Browser, y lo que encuentra le deja claro que este fin de semana no toca spa. Al parecer el CCN-CERT ha encontrado, gracias a su sistema de monitorización de la deep web, una hoja Excel con información confidencial del proyecto EHP (European Happy People).
El EHP es un proyecto de la Unión Europea que tiene como objetivos mostrar el optimismo, buen humor y calidad de vida de los ciudadanos de Europa. Liderado por España (y por ende, el MINAF), una de sus iniciativas principales ha sido la de montar un concurso (muy al estilo de Eurovisión) para buscar a los ciudadanos más felices de Europa. La respuesta ciudadana ha sido masiva, y más de 60.000 españoles han participado en el concurso, rellenando varios cuestionarios para estimar su nivel de felicidad.
Un jurado elegido por el MINAF ha realizado una larga deliberación a lo largo de casi dos meses, y ha generado una lista corta de candidatos para representar a España como “persona más feliz”… y esa lista corta es la que Ángela está viendo ahora mismo en su navegador.
Las consecuencias pueden ser gravísimas: además del impacto reputacional que puede tener para el MINAF un fallo de seguridad en la gestión de un proyecto europeo, los datos que los ciudadanos tenían que dar cuando rellenaban los cuestionarios podían llegar a ser muy sensibles. De confirmarse la brecha de seguridad, la posible sanción por incumplimiento del RGPD podría ser épica…
Ángela está 80% furiosa, 20% nerviosa. En los últimos 2 años el MINAF ha realizado un esfuerzo titánico de modernización TIC (gracias a toda la agenda de Transformación Digital liderada por el Gobierno).
Prácticamente la totalidad de los puestos de usuario son Windows 10 y los servidores son Windows 2016 Server y Red Hat Linux (con una cada vez mayor presencia de estos últimos). Todos los equipos tienen un antivirus actualizado, y se están llevando a cabo unas políticas de actualización estrictas (así como copias de seguridad para la información crítica). Hace poco se ha desplegado un sistema nuevo de IDS (Suricata) y de monitorización interna de la red con Bro, y se está empezando a probar CLAUDIA (la herramienta de monitorización de endpoint del CCN-CERT) en los puestos de escritorio (así como una buena cantidad de medidas de seguridad adicionales que Ángela se guarda en la manga y que a bien seguro no van a gustar a ningún atacante).
De forma adicional, la información relativa al proyecto EHP estaba sujeta a un nivel de seguridad adicional: CHITONSRV (el servidor Windows 2016 que almacena los datos) está situado en una red segregada a la que solo tienen acceso 6 altos cargos del MINAF y un administrador de sistemas senior (de total confianza). Ese equipo se ha configurado con un nivel de auditoría aumentado, y la BD donde se guardan todos los datos está cifrada con GnuPG (usando una clave RSA de 4096bits).
Ángela no va a decir que el MINAF es el sistema más seguro del mundo, pero desde luego puede afirmar que no son un blanco “blandito”. Está claro que tenemos un incidente de seguridad, así que Ángela se plantea los siguientes objetivos inmediatos dentro de la fase de análisis del incidente:
- Determinar el alcance del incidente: ¿cuántos equipos han sido comprometidos?
- Encontrar el vector de entrada de la posible intrusión.
- Estimar el impacto: saber si la base de datos de ciudadanos ha sido o no comprometida.
- Generar IOC (Indicators of Compromise) para aplicarlos en primera instancia en el MINAF y luego compartirlos con el resto de la AGE.
La experiencia es un grado, así que Ángela se pone inmediatamente manos a la obra. Lo primero que hace es generar una bitácora (un fichero de texto en su escritorio), para tener un seguimiento temporal de todos los hechos. El incidente se declara el viernes 7 de noviembre de 2019 a las 14:25h, y por ahora la única pista que tenemos reside en los accesos a CHITONSRV, así que vamos a investigar dicho servidor.
La medida más efectiva en estos casos es la de realizar una recogida de evidencias en caliente, ya que se puede realizar de forma rápida y sin afectar al funcionamiento del servidor (que en estos momentos no puede apagarse para un clonado forense porque está prestando un servicio crítico).
Salvador Bendito (uno de los administradores senior del MINAF) se encarga de realizar la adquisición insertando una memoria USB en el servidor con las herramientas winpmem y CyLR, y ejecutándolas desde un terminal con privilegios de administrador teniendo cuidado de guardar los resultados en el mismo USB. La operación se lleva a cabo en menos de 5 minutos (rapidísimo comparado con las 4-5h que podría costar clonar el disco de 1Tb del servidor).
Habiendo capturado las evidencias, se calculan en el portátil de Salvador los hashes SHA-256 de los dos ficheros mediante sha256sum (SHA-256 es un algoritmo a día de hoy seguro. Si por algún motivo solo puedes usar MD5 y SHA-1 … usa los dos porque, aunque puedes tener colisiones en uno u otro, no se conocen actualmente técnicas para tener una colisión en ambos a la vez):
MINAF_chitonsrv.mem feb99cba066ba12a5011b665df39880d4dbbaadacc61c0dfe5d236ff9f019728
MINAF_chitonsrv_triage.zip cec3a3254ace4dba3ec7ec794a1324e99330f5e6f50f2475429a9f3933b22721
Para asegurar las evidencias, se realizan dos copias: una en el portátil de Salvador y otra en otra memoria USB nueva que Ángela ha traído para la ocasión (que se entrega junto con el equipo del Subdirector a la Inspección General de Servicios para su custodia). Se documenta todo el proceso y tanto Ángela como Salvador vuelven a sus despachos para iniciar el análisis.
[Nota 3: Todo el entorno de pruebas está virtualizado en un servidor Proxmox remoto, en el que gestionar USB “virtuales” es un verdadero dolor. Es por ello que la captura se ha hecho en “modo cloud”: se ha añadido al equipo un disco duro con las herramientas, se han ejecutado y se ha retirado el disco. Esto no afecta significativamente al análisis, pero es necesario indicarlo para no inducir a confusión si un analista examina las evidencias en bruto].
El primer paso es validar las evidencias recibidas con la herramienta HashMyFiles que Ángela tiene en su equipo:
Paso 1.1: MFT
Una primera opción es la de intentar ver cuándo han sido accedidos los ficheros confidenciales en CHITONSRV, y así empezar a establecer el marco temporal del incidente. Para ello podemos convertir la MFT (extraída con los datos de triage gracias a CyLR) a un formato como .csv empleando la herramienta mftdump.exe
Como Ángela sabe que la carpeta confidencial se llama “Secreto”, hace un grep (sí, hay grep para Windows, y sí, findstr hace lo mismo pero cada uno elige las herramientas que quiere) y se queda con un .csv mucho más reducido (Excel funciona regular con .csv de 30Mb+, y en este caso tratamos con una de 115Mb, que hasta Calc de LibreOffice suda para abrirla).
Si buscamos por la documentación confidencial nos encontramos que, quitando la lista de candidatos, el resto de ficheros no han sido accedidos en varias semanas:
Esto puede tener dos explicaciones:
- Los atacantes han empleado herramientas de timestomping para alterar los tiempos MAC de los ficheros
- Los atacantes llevan MUCHO tiempo en la red del MINAF, y han podido robar esa información hace meses.
Paso 1.2: Logs de eventos
El siguiente paso es revisar quién ha iniciado sesión en el sistema, algo que podemos buscar en el log de eventos de Windows Security (específicamente en el EventID 4624, “Una cuenta ha iniciado sesión correctamente”). Sin embargo, el log está limpio como una patena: ni un solo evento con el id 4624:
El nivel de paranoia de Ángela va en aumento. Si los atacantes hubieran borrado los logs no saldría el resto de eventos… ¿habrán sido tan hábiles como para directamente deshabilitar la auditoría de los inicios de sesión?
Ángela sabe que las políticas de seguridad están en esta clave del registro:
HKLM\Security\Policy\PolAdtEv
Por lo que puede recuperar esa hive del registro de los datos de triage y abrirla con Registry Explorer:
El resultado es un chorro en binario ligeramente ininteligible. Menos mal que buscando por Internet Ángela encuentra una tool online que permite interpretar los resultados:
Y con un poco de un traductor online:
Ángela confirma su teoría: los atacantes no han modificado los logs de Security. En todo caso, han deshabilitado las políticas de auditoria, un movimiento muy hábil que empieza a hacer pensar a Ángela en que podemos estar frente a una APT (Advanced Persistent Threat).
Antes de pensar en que viene el coco (o sea, APT28), Ángela va a ser metódica y a revisar otras formas posibles de identificar quién ha podido iniciar sesión en el servidor. Dado que tenemos auditoría habilitada para la carpeta completa de Documentación (en la que se encuentra la carpeta Secreto), en el log de Security tendrían que aparecer dos nuevos eventos:
- EventID 5140: “Se tuvo acceso a un objeto de recurso compartido de red”.
- EventID 5145: “Se comprobó un objeto de recurso compartido de red para averiguar si se puede conceder el acceso deseado al cliente”.
Dado que existe un férreo control de accesos, para considerar que un acceso es exitoso tenemos que comprobar que tenemos un EventID 5140 + una serie de EventID 5145. Si revisamos el log de Security comprobamos que la única persona que ha accedido es María Feliz (Subdirectora General de Festejos del MINAF, y una de las personas autorizadas a acceder a CHITONSRV).
Ángela tiene todavía otra fuente de información: los accesos por Escritorio Remoto. Todos los inicios de sesión se quedan guardados en el log:
Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational
Por lo que puede revisar el EventID 1149: “Servicios de Escritorio remoto: autenticación de usuario correcta”, encontrando varias coincidencias:
El usuario supersecretadmin corresponde al usuario administrador del servidor, fuera de dominio y empleado únicamente por Salvador Bendito (el administrador de sistemas autorizado), desde cuya dirección IP (192.168.1.3) se ha realizado la conexión. Hasta ahora todo parece estar dentro de lo normal, así que Ángela necesita sacar la artillería pesada.
Paso 1.3: Sysmon
El MINAF está realizando un piloto de CLAUDIA, uno de cuyos componentes es Sysmon. Aunque no esté todavía conectado al servidor centralizado, el log de Sysmon se guarda en local, por lo que Ángela puede consultarlo dentro de los logs de eventos de Windows recogidos en el triage.
El log de Sysmon tiene una buena pila de eventos, así que Ángela decide reducir el campo de búsqueda a la creación de nuevos procesos (EventID 1), guardando solo esos eventos en un .csv.
Una vez aterrizados en un fichero de texto (el formato .evtx es binario, ojo), es posible hacer una revisión rápida realizando una búsqueda únicamente por los comandos ejecutados por el usuario SuperSecretAdmin:
type sysmon_eventid1.csv | grep SuperSecretAdmin | grep CommandLine > comandos_supersecretadmin1.txt
Si revisamos los comandos, encontramos uno que nos parece especialmente interesante:
SuperSecretAdmin ha abierto el README de la carpeta Secreto (y si nos fijamos, ha abierto poco después el vídeo que había en la carpeta). Este comportamiento es un poco anómalo, así que Ángela realiza una nueva búsqueda para acotar temporalmente estos accesos:
type sysmon_eventid1.csv | grep SuperSecretAdmin -B 5 | grep CommandLine > comandos_supersecretadmin2.txt
Antes de que nos metamos en harina, una puntualización necesaria: es MUY recomendable siempre que estamos haciendo una investigación el usar como referencia las horas UTC (Universal Time Coordinates) para tener un marco temporal estable y común. Hay pocas cosas peores en un forense que el mezclar horas y terminar buscando indicios en donde todavía no ha pasado nada… En España el 5 de noviembre estamos ya en horario de verano, por lo que nuestra hora es UTC+1.
Será por lo tanto necesario revisar qué herramientas nos dan la salida en hora UTC y cuáles la ofrecen en horario de España (ya que a estas últimas tendremos que restarles una hora para convertirlas a UTC).
En este caso, los logs de eventos marcan los sucesos en hora española, por lo que podemos ver que el usuario supersecretadmin ha abierto el fichero README.txt.txt el 5 de noviembre de 2019 a las 13:59:06 UTC.
¿WTF? ¿Pero qué clase de brujería es esta? En el apartado anterior hemos visto que, según la MFT, el fichero README.txt.txt había sido accedido por última vez el 25 de septiembre … pero Sysmon nos dice que fue accedido el 5 de noviembre ¿Qué está pasando aquí?
Ángela lleva mucho tiempo en este mundillo TIC… y más sabe el diablo por viejo, que por diablo. En su vida pasada, había trabajado como administradora de sistemas, y recuerda que mantener la fecha de último acceso podía impactar al rendimiento en algunos sistemas con mucha actividad, por lo que se solía deshabilitar.
En Windows este parámetro se encuentra en el hive SYSTEM:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate
Por lo que un poco de Registry Explorer nos confirma lo que Ángela sospechaba:
En efecto, el tiempo de último acceso está deshabilitado, lo que explica la diferencia de comportamientos entre lo que muestra la MFT y lo que nos deja ver Sysmon.
Rebuscando un poco entre la documentación de Microsoft, nos encontramos que tanto este comportamiento como el de la falta de logs de los inicios de sesión no es ninguna configuración maliciosa por parte de un atacante avanzado … sino el valor que Windows 2016 Server trae por defecto:
Las blasfemias que se oyen en el despacho de Ángela harían sonrojar a un árbitro de segunda B, tres camioneros y dos docenas de estibadores marselleses. Tras un par de minutos de desahogo espiritual (y lamentando no haberse traído la botella de DYC 15 años al trabajo), Ángela se recompone y prosigue con la investigación siguiendo su único hilo disponible: la apertura de ficheros confidenciales por parte de supersecretadmin, algo altamente irregular.
Con este nuevo dato, Ángela peina con cuidado de nuevo todos los logs disponibles… y encuentra un ítem que había pasado por alto la primera vez que revisó el log de eventos de Security:
En ese log, el usuario SuperSecretAdmin intenta montar a través de SMB el recurso administrativo C$, algo equivalente a decir “dame acceso a todo el disco duro del servidor”. Dado que no observamos un EventID 5145 podemos asumir que el acceso no ha sido exitoso… pero esta acción es tremendamente irregular, y viene del mismo equipo que inició sesión en CHITONSRV: 192.168.1.3, el puesto de trabajo de Salvador Bendito.
Algo raro está pasando aquí… y lo veremos en el siguiente artículo.
