Yara es una iniciativa que cada vez va consiguiendo un mayor uso en el ámbito de la gestión de incidentes, en especial este último año. Este proyecto ha sido ampliamente comentado en artículos de este y otros blogs.
En esta ocasión voy a mostrar un ejemplo práctico del uso de yara para la gestión de incidentes provocados por ransomware. Estos últimos meses ha habido un aumento de actividad de este tipo de malware que, a pesar de las numerosas advertencias realizadas por aquellos que nos dedicamos a la seguridad y la gestión de incidentes, sigue teniendo un impacto bastante grande. Afortunadamente, los últimos incidentes de ransomware en los que he participado, el compromiso únicamente ha afectado a un usuario en cada caso, lo que ha permitido centrarnos más en el alcance de los archivos cifrados que en la identificación de posibles equipos comprometidos.
Identificación de extensión
Uno de los primeros casos en los que tuvimos que participar fue un incidente con CTB-Locker. En esta ocasión, un usuario reporta un mensaje que le aparece en su escritorio informando que sus archivos han sido cifrados y se solicita un rescate para su recuperación. Una vez contenido parte del incidente desconectándolo de la red e identificando que es el único equipo afectado (no vamos a extendernos en este punto) pasamos a determinar qué archivos han sido cifrados y cuáles pueden recuperarse (nunca recomendamos pagar por su rescate).
Por supuesto, muchos de los archivos locales fueron cifrados y no se pudieron recuperar pero aquellos que estuvieran en recursos compartidos sí sería posible. Aprovechamos para recordar que aquella documentación relevante para la organización no debe dejarse en recursos locales, sino en servidores centralizados por muchos motivos (entre ellos, por hacer copias de seguridad y cotrolar la salida de información de la organización).
Una vez analizado el incidente en el equipo local, se determinó que los archivos que se cifraron se les añadió una extensión .GHHURFF. Sabido esto, no fue necesario definir una regla Yara, ya que una simple búsqueda de archivos con dicha extensión en el Explorador de Windows o un simple find en sistemas GNU/Linux nos mostró un resultado aceptable y en un tiempo muy corto.
Encabezado
Otro caso con el que nos encontramos relacionado con ransomware fue uno donde los archivos que cifraba el malware no les añadía una extensión sino que la mantenía, así que ahora sí teníamos que desarrollar una regla Yara.
Tras analizar su contenido, nos dimos cuenta que todos los ficheros, independientemente del tipo de archivo que se trataba, comenzaban con los mismo bytes ({4d 12 03 df b2 2b 2e f1 d0 3e 4e b5 8d 01 0c 27 }).
En este caso, la regla creada en Yara era la siguiente:
rule ransomware : Ransomware
{
meta:
author="S2 Grupo"
date="10/03/2015"
description="Detection ransomware infection"
strings:
$signature1={4d 12 03 df b2 2b 2e f1 d0 3e 4e b5 8d 01 0c 27}
condition:
$signature1
}
De esta forma se identificaron numerosos archivos, sin importar la extensión que tuviera o el tipo de documento.
Magic number
Otro de los últimos incidentes relacionados con ransomware en los que participamos no contemplaba ninguno de los casos anteriores, por lo que tuvimos que identificar qué patrón tenían en común los archivos cifrados.
Una primera idea fue utilizar la función de cálculo de la entropía, ya que pensamos que el cifrado aleatoriza los bytes de los archivos, aumentando así la entropía de los mismos. Esta aproximación no pudimos llevarla a cabo ya que era complejo determinar un número que fuera indicativo de que se trataba de un archivo cifrado (esta solución la dejaremos para ejercicios posteriores).
Tras la alta tasa de falsos positivos que provocaba la regla anterior, se optó por tratar de identificar el tipo de archivo de los documentos. Si el archivo se cifra, de forma que modifica el magic number de los archivos, este se inutiliza y pasaría a detectarse como “data”. Para esto se hizo uso del módulo magic (no disponible en la versión para Windows)
rule magic_data_type: Trojan
{
meta:
author="S2 Grupo"
date="12/03/2015"
description="Data mime type"
condition:
magic.type() == "data"
}
Aquí aparecieron algunos falsos positivos, pero teniendo en cuenta la extensión de los archivos, se pudo separar de los que estaban cifrados para su recuperación.
Conclusiones
En todos los casos anteriores el impacto de los compromisos fue muy bajo gracias a que las políticas de copias de seguridad de las diferentes organizaciones permitieron recuperar los archivos cifrados de copias anteriores y las jornadas de concienciación formaron a los usuarios sobre los peligros del correo electrónico y su uso seguro permitieron que el número de usuarios afectados fuera menor. De esta forma nos pudimos centrar más en la identificación del punto de entrada del malware y de los ficheros cifrados para recuperarlos, que en las fases de contención y erradicación, ya que en todos los casos se trataba de pocos usuarios a los que se les plataformó el sistema de cero.
Hay que destacar que en todos los casos anteriores el número de archivos cifrados ascendía a decenas de miles de archivos, por lo que el impacto de no poder haberlos recuperado de copias anteriores hubiera sido importante.
