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.

El viejo WinPrefetch nos da resultados con eficiencia sobre la carpeta c:\windows\Prefetch del equipo de Salvador. Después de un rato revisando todos los ejecutables, Ángela detecta dos anomalías.  En primer lugar, la ejecución del programa “útil1.exe” el 4 de noviembre:

Ese programa ha sido ejecutado desde una carpeta MUY extraña dentro del espacio del usuario salvador.bendito, y además se ha ejecutado el 4 de noviembre (justo el día antes de toda la actividad maliciosa).

En segundo lugar, pocos minutos antes de util1.exe aparece un conjunto de ejecuciones en línea de comandos:  arp.exe, ipconfig.exe, nbtstat.exe y ping.exe. Si esto no es una actividad de reconocimiento de un equipo en toda la regla, que todas mis particiones se llenen de /dev/null.

Paso 2.5 MFT reloaded

En el paso anterior Ángela ha detectado un ejecutable bastante interesante, así que va a intentar localizarlo (sin muchas esperanzadas) en la MFT:

¡Bingo! Al menos en esa parte ha habido algo de suerte. Además, no solo hemos encontrado el fichero dentro de la imagen, sino que además hemos visto una carpeta altamente sospechosa dentro de C:\Windows\SysWOW64.  Vamos a obtener todos los ficheros y a calcular sus hashes con HashMyFiles:

… y vamos a ver qué nos dice VirusTotal sobre estos ficheros (recordad, en caso de sospecha de APT nunca, nunca nunca se suben las muestras a VirusTotal, se suben los hashes). La cosa parece bastante clara:

Parece que el veredicto es el mismo en ambos casos ¿Y qué demonios es Refog?

Una búsqueda rápida en Internet nos da información muy reveladora:

Refog es un keylogger es un spyware en toda la regla, con capacidades de captura de pantalla, monitorización de la navegación y la mensajería instantánea … y por supuesto, keylogger.

Estas evidencias arrojan a priori otras luces sobre el caso, sobre todo cuando Ángela intenta localizar en el historial de navegación web de Salvador la descarga del keylogger, y no la encuentra por ninguna parte (sí que encuentra en la carpeta de descargas el instalador de TeamViewer, algo curioso) ¿De dónde ha podido salir el Refog?

Paso 2.6 Logs de Eventos

Mientras le da vueltas a esa cuestión, Ángela revisa los logs de Security para tener saber quién ha iniciado sesión en el equipo.  Sabiendo los distintos tipos de inicio de sesión, Ángela está muy interesada de nuevo en el EventID 4624 (inicio de sesión), específicamente en aquellos en el que el inicio es tipo 10 (RemoteInteractive), que es el que se produce cuando alguien entra a través de Escritorio Remoto… Pero no encuentra ni un solo acceso de estas características.

Peinando los accesos, Ángela encuentra principalmente tipo 5 (Servicio), 4 (acceso a través de la red), ambos al parecer relacionados con cuentas de Sistema y Equipo, y varios accesos tipo 2 (cuando el usuario está delante del teclado) y tipo 7 (desbloqueo del terminal). Sin embargo, después de quemarse las pestañas un buen rato, Ángela encuentra algo muy interesante:

Ahí podemos encontrar un acceso al equipo desde la cuenta de salvador.bendito, con origen en el equipo WEBSERVER (mucho cuidado, en una primera revisión Ángela paso por alto esta conexión pensando en que era en sentido inverso, ADMINPC1 à WEBSERVER). 

Para confirmar que esta conexión se ha realizado como piensa, accede a los logs de Terminal Server (ojo, de las conexiones que se han realizado contra ADMINPC1, no desde ADMINPC1):

Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational

En efecto, ahí tenemos nuestra conexión perfectamente cuadrada en ambos logs. Ángela está ojiplática: ¿pero no quedábamos que los inicios de sesión a través de Escritorio Remoto eran tipo 10?

Después de buscar un rato por Internet, Ángela encuentra un blog en el que se ofrece una explicación a este comportamiento tan anómalo: si está habilitado NLA (Network Level Authentication), el tipo de inicio de sesión se registra como 3 en lugar de 10.

Bueno, vamos a comprobarlo. El valor de configuración de NLA se puede encontrar en la clave del registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer

Que podemos abrir con Registry Explorer y comprobar que tenemos a valor 2:

Según la documentación oficial de Microsoft, si ese valor es igual a dos tenemos el nivel más alto de autenticación posible, lo que equivale en la ventana correspondiente a esto:

Si no fuera algo tan importante, Ángela habría dicho “a tomar por culo ya, ostias ya” y se habría ido a su casa. A pesar de la mala leche, ha sacado dos piezas de información críticas para nuestra investigación:

• El equipo ADMINPC1 admitía conexiones de Escritorio Remoto
• Se han producido conexiones desde un servidor web del MINAF hacia este equipo.

Trabajando con cuidado, Ángela peina los logs de Escritorio Remoto tanto de ADMINPC1 como de CHITONSRV, y es capaz de ofrecer un nuevo escenario mucho más complejo pero esclarecedor:

Si nos damos cuenta, los atacantes se han conectado en dos días consecutivos: el día 4 de noviembre entran en ADMINPC1, realizan un reconocimiento del sistema y despliegan un keylogger.

El día 5 de noviembre, Salvador Bendito entra a media mañana a CHITONSRV, dejando las credenciales grabadas en el keylogger. Unas horas después, los atacantes entraron de nuevo en ADMINPC1 a través de WEBSERVER, recogieron las credenciales del keylogger y accedieron a CHITONSRV, realizando toda la copia y posterior exfiltración vía TeamViewer de la carpeta Secreto.

A esta distancia Salvador Bendito parece inocente, pero Ángela tiene que estar segura al 100%, y para ello necesita revisar WEBSERVER. El resultado del análisis, en el artículo siguiente…