Amenaza Silenciosa I
Amenaza Silenciosa I
Amenaza Silenciosa II – Inyección de DLL
Amenaza Silenciosa III – Hooking (Teoría)
…
Cuando trabajo cazando malware, una de las cosas que suelen cantar a la hora de encontrar artefactos maliciosos es la aparición de ejecutables extraños en los sistemas de persistencia más comunes, como, por ejemplo, en algunas claves de registro. Un día me pregunté, ¿es posible generar una amenaza silenciosa, que no cante mucho en los sistemas de persistencia, sin utilizar técnicas extrañas? Veamos como de fácil o difícil sería.
Dridex
No es la primera vez que hablo de temas relacionados con Dridex en este blog. En este caso lo hablaré de su mecanismo de persistencia. Es un sistema simple pero efectivo que da muchos dolores de cabeza a los administradores de sistemas a la hora de eliminarlo de una red.
Una vez infectado con Dridex, al ejecutarse, este se inyecta en el proceso Explorer.exe y se borra del sistema. Pero, ¿cómo logra entonces persistir?
Cuando Dridex detecta que Windows se va a cerrar se escribe a si mismo con la estructura <nombre aleatorio>.TMP y añade a la clave de registro HKEY_CURRENT_USER\ Software\Microsoft\Windows\CurrentVersion\Run el valor:
"rundll32.exe C:\DOCUME~1\\APPLIC~1\ .tmp NfInitialize"
Cuando se vuelve a ejecutar el reiniciar el sistema, el fichero .TMP se vuelve a borrar y la clave del registro desaparece.
Esto no sólo hace su detección muy complicada, ya que la mayoría de los antivirus funcionan analizando los ficheros en disco y los que analizan la memoria no analizan todas la páginas, si no que la manera más fácil y barata de desinfectar las maquinas es desenchufándolas y quitándoles la batería si son ordenadores portátiles, lo cual complica la desinfección. ¿Os imagináis que gracia le hará al que le toque ir desenchufando dos mil ordenadores?
Sin utilizar ninguna técnica nueva, esto consigue que la detección en base a la aparición de artefactos sospechosos en sistemas de persistencia de la que hablaba en la introducción sea imposible una vez Windows ha arrancado: ni vamos a encontrar un ejecutable en %TMP% o %APPDATA% , ni vamos a ver nada en las claves del registro.
Alternate Data Streams
Alternate Data Stream (ADS) es una característica de NTFS en principio diseñada para almacenar información sobre un ficheros sin tener que utilizar otros ficheros. Estos metadatos se escriben en el disco duro a continuación de los datos del fichero.
Si miramos un registro de la Master File Table (MFT) de NTFS, se puede ver la diferencia entre un fichero sin ADS y uno con ADS.
Registro de fichero en MFT:
Registro de fichero en MFT con ADS:
Images extraídas del documento: Alternate Data Streams: Out of the Shadows and into the Light de Ryan L. Means (2003).
Como se puede ver, en el registro con ADS aparece un segundo stream de datos después de los datos del fichero.
En el pasado se han utilizado ADS para ocultar malware y ejecutarlo desde ahí.
Con la llegada de Windows 7, Microsoft deshabilitó la posibilidad de ejecutar directamente nada que estuviera almacenado en ADS. Aun así, hay formas indirectas de ejecutar estos binarios.
Infección de ficheros
Una de las cosas que me lleva a escribir esta serie de artículos es la siguiente hipótesis: ¿y si en lugar de añadir un nuevo binario a cualquiera de los sistemas de persistencia infectamos un binario que ya esté en uno de estos mecanismos?
Es decir, aprovechando la estructura de los ficheros PE, ¿puedo inyectar mi programa en un ejecutable que previamente he detectado que persiste?
La respuesta es, en principio, que sí, puedo. La realidad es que no sé cual será la dificultad de realizar esto en sistemas operativos modernos, pero lo que sí que sé es que en muchos proyectos de “compromise discovery” * pasaría desapercibido.
Objetivos
Este post es sólo la introducción a un viaje en el que sólo he empezado a dar los primeros pasos en el que voy a tratar de replicar las técnicas comentadas en el post y del que espero volver con los siguientes resultados:
- Aumentar mi conocimiento de inyección de procesos en Windows.
- Mejorar y terminar de comprender cómo funcionan el hooking de funciones en Windows.
- Conocimiento profundo de los diferentes métodos de persistencia en sistemas Windows.
- Comprender el sistema de ficheros NTFS.
- Ver como funciona la infección de ficheros a nivel práctico.
- Aplicación de las técnicas clásicas de infección en un entorno moderno.
- Profundizar en la API de Windows.
¿Qué puede esperar el lector?
- Un montón de referencias y enlaces a recursos que utilice.
- Pruebas de concepto (al menos de las partes relevantes).
- Los resultados explicados tan bien como pueda.
- Largas esperas y poca periodicidad :P.
Mientras sigo pasito a pasito, ¿se os ocurre alguna otra técnica o forma de hacer que un bicho pase desapercibido y se me haya pasado?
* Compromise discovery es el nombre que reciben los proyectos en los que un equipo con conocimiento en respuesta ante incidentes se presenta en una compañía, toma un “snapshot” de los sistemas de la compañía y analiza esa información en busca de evidencias de compromiso.
Me encanta participar en CTFs y últimamente estoy cacharreando con temas de hardware.
Ver descripción | Ver perfil en LinkedIn
- Introducción a Frida - 1 junio, 2016
- De Charleta: “Android Application Function Hooking with Xposed” (Jamie Geiger) - 23 mayo, 2016
- De Charleta: “Introducing the RITA VM: Hunting for bad guys on your network for free with math” (John Strand, Derek Banks, Joff Thyer, and Brian Furhman) - 9 mayo, 2016
