[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.
Cuando termina la conversación, Ángela se apunta la necesidad de comprar un lanzallamas como el de Elon Musk. No, no será suficiente. Necesita napalm. MUCHO napalm. Apocalypse Now va a parecer un anuncio de mecheros comparado con la que va a liar en la próxima reunión entre áreas TIC del MINAF:
WEBSERVER es un servidor web Windows 2008 perteneciente al área de Desarrollo, que había sido pasado a Preproducción porque era el que contenía el desarrollo del proyecto “Happyzate” (para crear y compartir contenidos felices entre los distintos organismos de la AGE). El proyecto llevaba varios meses de retraso, así que algún pez gordo tuvo la brillante idea de ordenar su paso a Producción “estuviera como estuviera”, porque había que presentarlo a finales de noviembre. Y claro, la mejor forma de que estuviera “para hoy” era pasarlo directamente de Desarrollo a Producción.
¿Se ha auditado de forma previa a su paso a Producción? No. ¿Se ha parcheado correctamente de acuerdo a la política establecida? Dudosamente. ¿Se ha bastionado siguiendo adaptación propia del MINAF de las guías de buenas prácticas del CCN-CERT? Já. ¿Se han establecido las políticas correspondientes en el cortafuegos? Me parto de risa.
Sabiendo a lo que se enfrenta, Ángela localiza en el CPD el servidor de marras, y repite el mismo procedimiento que con CHITONSRV: memoria USB con winpmem y CyLR, ejecución y volcado de resultados en la misma memoria USB. Y, teniendo un presentimiento, se copia el directorio raíz del servidor web (C:\inetpub). Es más que probable que lo necesite a lo largo de la noche, y así se ahorra otro viajecito al CPD.
Dado que son casi las 23:00h de la noche, no hay nadie para que firme la hoja de adquisición, y Ángela piensa en lo irregular del proceso de adquisición … pero le da igual. Tiene a un compañero en el calabozo, y en la subdirección TIC NO-SE-DEJA-A-NADIE-ATRÁS.
Ángela calcula con sha256sum los hashes de los 3 ficheros:
MINAF_webserver_triage.zip 62664245071a72af2452bba2d3912099295d7bf813df25eaad596765a5639f9c
MINAF_webserver_inetpub.tar.gz 11fc7504193969d65324743cbcc6023780a85b036d35efa2aebba91b2a3e52a3
MINAF_webserver.mem 41746ee80471d9b84ea216c7f9fa48e8fbe3b95d140f482722ea8c9f1d4984ed
Una vez calculados, realiza una copia de las evidencias en su puesto de trabajo y guarda la memoria en su cajón. Ángela está exhausta, pero el entrenamiento hace que funcione de forma automática, y calcula de nuevo los hashes con HashMyFiles:
Paso 3.1 Logs de Eventos
Ángela tiene claro por dónde empezar: quiere saber qué usuarios han iniciado sesión en el equipo, así que se lanza a por el log de Security del servidor. El primer inicio que encuentra es el salvador.bendito el 3 de noviembre a las 19:31h UTC
Es un acceso en domingo (algo raro), pero se ha realizado desde su puesto de trabajo (Salvador, como administrador de sistemas senior, tiene acceso por VPN + 2FA a su equipo). Ángela sigue buscando inicios de sesión, y el siguiente que encuentra la deja muerta:
Inicio de sesión con Escritorio Remoto (logon type 10, recordad) … ¡pero de una IP de Internet! ¿Cómo han podido hacer eso? ¿Por qué Comunicaciones ha permitido ese acceso? Patidifusa, Ángela revisa los logs de TerminalServices-RemoteConnectionManager para obtener más información de lo que ha sucedido, y localiza tanto el inicio de Salvador como el de la IP maliciosa. Y de paso, encuentra una anomalía:
¿Quién es el usuario SzEkCtN? ¿Cómo ha podido iniciar sesión en el equipo? Y sobre todo… ¿Por qué no ha dejado log en Security? Ángela revisa las entradas del log y encuentra otro acceso anómalo, que tampoco se refleja en Security:
Algo raro está pasando, y necesitamos saber qué. Ángela se dedica a mirar con lupa todos los logs del servidor, y encuentra otro ítem de interés:
El equipo se ha reiniciado de forma inesperada … 3 min después de la primera conexión por Escritorio Remoto con usuario aleatorio, y apenas 10 minutos después de la segunda conexión. Ángela está al día de lo que pasa en ciberseguridad: Acceso por Escritorio Remoto + reinicio del equipo + Acceso por Escritorio Remoto apuntan a una cosa. Una búsqueda en Internet confirma sus sospechas:
https://adraft.page/index.php/2019/10/07/metasploit-bluekeep-cve-2019-0708-exploit-logs-analysis/
Los atacantes han usado el exploit CVE-2019-0708 (también conocido como BlueKeep) contra WEBSERVER, y en la primera ocasión no han debido acertar en la elección de parámetros y han causado un BSOD (Blue Screen Of Death, “pantallazo azul de la muerte” para los amigos), lo que ha provocado el reinicio del equipo.
El segundo inicio de sesión parece limpio, por lo que lo más probable es que los atacantes lograran conseguir entrar en el equipo. El acceso posterior por Escritorio Remoto se realiza desde la misma IP, por lo que los atacantes logran consolidar el acceso en menos de 20 minutos.
Ángela abre el log de Sysmon, ansiosa por ver con todo detalle qué diabluras han cometido los atacantes… pero el log se ha llenado, y solo tenemos información desde el 3 de noviembre a las 23:35h UTC (el log de Sysmon por defecto son 64Mb, y si por algún motivo se llena, los eventos más viejos se borran para escribir los nuevos en lo que se llama “log circular”).
Es momento de volver a los básicos: Ángela vuelve a parsear la MFT del servidor, y con un margen temporal muy acotado (3 de noviembre a partir de las 19:30h UTC), tarde muy poco en encontrar resultados:
Ángela no tiene una copia del disco así que no puede extraer el feliz.exe. Revisando la memoria con Volatility, se da cuenta de que el servidor se apagó también el 4 de noviembre, por lo que no vamos a poder extraer el fichero con dumpfiles. De todas formas, el otro fichero hace pensar a Ángela: sobre 35Mb, con extensión .dmp …. ¡Esto tiene toda la pinta de un procdump!
Mimikatz (o sus variantes) es una de las herramientas más empleadas por los atacantes para poder robar credenciales y de esta forma moverse por la red. Sin embargo, al ser considerado uno de los “Enemigos Nº1”, muchas herramientas de seguridad son capaces de detectarlo … así que los atacantes han seguido otros caminos.
Mimikatz tiene un método de operación offline: si se le facilita un volcado de memoria del proceso lsass.exe (donde se guardan las credenciales), es capaz de operar exactamente igual que sobre el equipo remoto. Y claro, es mucho más sencillo desplegar en el equipo procdump.exe (una herramienta del kit de herramientas Sysinternals de Microsoft), realizar un volcado y exfiltrarlo … que es lo que Ángela sospecha que han realizado los atacantes en este caso.
Una descarga de la herramienta, y una comparación rápida nos deja ver que tienen exactamente el mismo número de bits, lo que confirma nuestra teoría. Además, encaja con lo visto en los logs con el acceso posterior con la cuenta de salvador.bendito. Ángela tiene en su mente la siguiente línea de hechos granulares:
- Los atacantes realizan el primer intento de explotar BlueeKeep, y cuelgan el servidor.
- Salvador.bendito entra al equipo para revisar qué ha podido pasar.
- Los atacantes realizan el segundo intento de explotar BlueeKeep, y tienen éxito.
- Suben procdump al servidor, y vuelcan la memoria de lsass.exe, descargando el fichero.
- Ejecutan Mimikatz offline, y obtienen las credenciales de salvador.bendito
- Entran por Escritorio Remoto “como unos señores vikingos”.
Ángela ya tiene bastante claro lo que ha sucedido, y solo le queda una mosca detrás de la oreja: siendo el equipo un servidor web de cara a Internet, no se cree que los atacantes se apoyen únicamente en las credenciales de salvador.bendito (que se renuevan de forma mensual).
Si ella fuera la atacante, se habría dejado un acceso secundario al sistema para poder volver a entrar aunque ya no tuviera credenciales: en este caso, una webshell. Revisando la MFT no tarda en encontrar el “regalo de Reyes” de los atacantes:
Ángela sí que se había llevado una copia del C:\inetpub, así que puede abrir el fichero sin problemas:
En efecto, una webshell de libro. Con una cierta búsqueda por Internet logra hasta encontrar el tipo exacto: Laudanum.
Ángela respira satisfecha, porque ya tiene todo lo que necesita por hoy. Aunque ya es pasada la medianoche, no le tiembla el pulso a la hora de llamar a la Subdirectora General y explicarle todo lo sucedido. La SG entiende la situación a la perfección, y llama a la Policía Nacional para que liberen a Salvador Bendito.
Mientras tanto, y dadas las horas (Ángela lleva en pie casi 20h, y está exhausta), decide tomar medidas de contención básicas: apagar todos los equipos afectados en el incidente. Mañana será otro día.
El resultado de la investigación, en el siguiente capítulo…
