Paso 3: Logs de eventos
En la entrada anterior dejamos a Ángela blasfemando por la manera en la que los atacantes habían empleado un antiguo dominio del MINAF para realizar su ataque. Ahora toca comprobar lo sigilosos que han sido revisando los logs del sistema.
Todo equipo Windows tiene un registro de eventos, situado en los equipos modernos en:
C:\Windows\System32\winevt\Logs
Existen diversos registros en función de los eventos que se guardan. Los clásicos son Seguridad, Sistema y Aplicación, pero a día de hoy tenemos varias docenas más de registros, que en algunos casos nos pueden dar información vital. Estos registros se guardan en formato binario, por lo que necesitamos algún programa para abrirlos.
Lo más profesional sería emplear LogParser, pero Ángela sabe que el humilde Visor de Eventos suele ser en muchos casos más que suficiente (y que puede abrir tanto los logs del propio equipo como los de otros equipos). En primer lugar, tenemos que gestionar las timezones. En este caso el Visor de Eventos trabaja con la hora del propio equipo, por lo que estaremos en UTC+1 y por ello tendremos que buscar actividad sospechosa el 3 de Noviembre alrededor de las 11.00h.
Todo evento que se guarda en un log de Windows tiene un identificador de evento (EventID) que permite identificar numéricamente a todos los eventos en Windows (aunque puede diferir en cada versión de Windows, por lo que siempre se aconseja el contrastar la información).
El log de Security suele ser el más jugoso, ya que contiene los inicios de sesión (EventID 4624), pero suele ser el más volátil ya que suele estar lleno de eventos y el tamaño por defecto es muy pequeño (en el MINAF suelen almacenar 3-4 días de eventos). Además hay que tener en cuenta que son blanco habitual para los atacantes, que los borran sin remordimientos para cubrir sus huellas.
Por eso mismo Ángela tiene un as en la manga: el humilde y trabajador log de perfiles de usuario (Microsoft-Windows-User Profile Service%4Operational.evtx), que guarda todas las operaciones relacionadas con los perfiles de usuario. Cada vez que se inicia sesión en un equipo (ya sea en local o en dominio) se carga el perfil del usuario (si alguna vez has iniciado por primera vez sesión en un Windows a lo mejor te suena unas ventanitas pequeñas que aparecen en la esquina superior izquierda que dicen “Configurando XXX” … ese es tu perfil de usuario siendo creado).
La buena noticia es que cada vez que se carga un perfil de usuario se genera un evento con EventID 5. El hecho de que este log sea muy específico hace que tenga una alta durabilidad, sumado a que suele pasar desapercibido a los atacantes, lo convierte en uno de los mejores amigos de un analista forense.
Analizando este log encontramos una pieza de información interesante:
Al parecer poco antes de la actividad maliciosa la cuenta dom.adm (un administrador de dominio) había iniciado sesión en el equipo, un dato significativo que genera múltiples preguntas: ¿Habrán conseguido los atacantes las credenciales del administrador de dominio? ¿Qué hacía exactamente esa cuenta en ese equipo minutos antes del incidente?
Otro de los logs que suele dar buenas pistas es el de Sistema, que almacena todo lo relevante que ocurre en el equipo. En este caso Ángela encuentra una prueba bastante contundente de que el equipo está comprometido:
¿Un servicio con nombre aleatorio y además recién instalado en el sistema y con un cmd.exe? ¡Qué me estás contando! Si Ángela tenía alguna duda de si este equipo estaba o no comprometido quedan disipadas al ver este log. Ahora que sabe a ciencia cierta que el equipo tiene “premio” Ángela sabe lo que tiene que hacer: ir de caza.
Paso 4: Persistencia
Buena parte de los atacantes pretenden permanecer en un sistema comprometido durante mucho tiempo. Para ello necesitan obtener persistencia, que en nuestro ámbito es la capacidad de seguir ejecutándose en el equipo, sobreviviendo incluso a un reinicio.
Existen diversos mecanismos de persistencia (claves Run, tareas programadas, servicios, eventos WMI), pero todas ellas tienen algo en común: se almacenan en el registro de Windows. Tenemos dos tipos principales de persistencia: en espacio de usuario (cuando el atacante no tiene privilegios de administrador) y en espacio de sistema (cuando el atacante ha conseguido privilegios de administrador).
El análisis de los diversos mecanismos de persistencia es fundamental en un análisis forense, ya que si localizamos la persistencia, estamos localizando de forma efectiva el malware de los atacantes. Una herramienta muy útil para analizar los mecanismos de persistencia es Autoruns, pero nos da problemas para ejecutarla con la escasa información que recoge CyLR.
Ángela suspira y se remanga la camisa: va a tocar hacer las cosas de forma manual con RegRipper, la herramienta forense casi por defecto de análisis del registro de Windows. En este caso se lleva una grata sorpresa al encontrar que RegRipper tiene un interface gráfico (a lo mejor lo tenía desde hace años, es la costumbre de la línea de comandos).
Obtener resultados de todos los plugins de RegRipper es tan sencillo como lanzarlo primero sobre el hive SOFTWARE del registro (donde está el HKLM, espacio de sistema) y a continuación sobre cada uno de los hive NTUSER.DAT de cada usuario (donde está el HKCU, espacio de usuario).
Ángela decide analizar los resultados por orden de probabilidad. Aunque hay mecanismos muy complejos que permiten conseguir persistencia, el uso de claves Run está muy extendido por su sencillez y rapidez. En el caso de RegRipper obtenemos esos valores con los plugins soft_run (SOFTWARE) y user_run (NTUSER.DAT). Una revisión rápida permite comprobar que no tenemos nada ejecutándose al inicio del equipo:
En el caso de los usuarios, la cosa es “ligeramente” distinta:
Ángela agita el puño en el aire conteniendo un “te pillé hijo de p…”. Lo que se ve con prístina claridad es un script de Powershell que se ejecuta desde la clave “Felicidad 2.0” (un nombre sospechosamente parecido a una aplicación interna del MINAF) que carga su contenido desde otra clave del registro, Felicisoft.
Para comprobar el contenido de esa clave Ángela hace uso de RegistryExplorer, que permite cargar hives del registro offline, en este caso la del usuario pepe.contento. El resultado habla por sí mismo:
Dentro de la clave Felicisoft tenemos la variable Happisoft, que en nuestro caso contiene un chorizo de letras y números… que cualquier ojo entrenado como el de Ángela reconoce automáticamente como codificado en base64.
Este análisis ha sido especialmente provechoso, ya que hemos obtenido lo que sospechamos: el malware que se arranca en el inicio de sesión del usuario pepe.contento (ojo, al ser persistencia en espacio de usuario tan solo se ejecuta cuando el usuario en cuestión inicia sesión).
Pero además tenemos otra joya: un IOC de alta calidad que nos permite determinar con certeza si un equipo o no está comprometido. En este caso el IOC es la existencia de la clave Felicisoft en el registro de usuario, algo que se puede verificar con relativa sencillez (un .bat que ejecute una query con el comando reg, distribuida como GPO en la Organización).
Es la hora de coger ese código base64 y apalearlo hasta que confiese. Ángela sabe que Salvador lleva varios meses haciendo cursos de análisis de malware, así que le va a encargar el análisis mientras ella analiza la memoria del equipo.
Los resultados de ambos análisis (y alguna que otra mala noticia), en la siguiente entrada…
