Detección de código malicioso con YARA (I)

¿Qué es YARA y para qué sirve?

YARA es una herramienta de código abierto para la identificación de malware la cual utiliza una gran variedad de técnicas. Su principal característica es su flexibilidad. Además, es de gran ayuda en situaciones de respuesta a incidentes, en las cuales tanto las herramientas como el tiempo, suelen ser limitados.

En este post vamos a crear un par de reglas para detectar payloads específicos de Metasploit y de Veil-evasion.

Escribir reglas para YARA es bastante sencillo. Aunque YARA ofrece multitud de opciones para crear reglas, solo hay que entender unos conceptos básicos para empezar. Observemos el siguiente ejemplo.

Regla YARA de ejemplo

rule SAW
{
        meta:
                descripcion = "Ejemplo regla para los lectores de SAW"
        strings:
                $cadenaDeBytes = { 53 41 57 }
                $cadenaDeTexto = "securityartwork.es"
        condition:
                $cadenaDeBytes and $cadenaDeTexto
}

La regla anterior contiene dos palabras claves : strings y condition. Los strings son las cadenas que hemos definido y que YARA buscará en el binario, mientras que la “condition” es la condición específica de los criterios para que se produzca su detección.

En esta regla, tanto el patrón de bytes como la cadena de texto deben coincidir y aparecer para que se produzca una detección.

La mayoría de las reglas que se crean para YARA tendrán estas dos palabras clave: strings y condition.

Ahora que ya tenemos una visión básica de cómo funcionan las reglas YARA, vamos a pasar a crear nuestras primeras reglas.

Regla YARA para meterpreter de Windows creado con Veil evasion

La primera regla que vamos a crear estará orientada a detectar un reverse TCP de Veil-evasion (c:/meterpreter/rev_tcp).

Para ello, tras examinar varios payloads con mi editor hexadecimal favorito (BLESS), identificamos que la IP del payload siempre está en el mismo offset de binario (0x28df). Con esta información ya podemos crear nuestra regla.

rule HardcodeHunter
{
        meta:
                descripcion = "Veil Hardcoded IP"
        strings:
                $IP = /(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.
                      (25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.
                      (25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.
                      (25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)/
        condition:
                $IP at 0x28df
}

La condición para que se cumpla esta regla es que se encuentre la expresión regular que busca el patrón de una IP en el offset que le estamos indicando.

Como podemos observar en la ilustración anterior, la regla ha sido todo un éxito y ha detectado la expresión regular que busca la IP en el offset 0x28df.

Regla YARA para meterpreter genérico de Windows creado con Msfvenom

Una vez creada nuestra primera regla, pasamos a nuestra segunda regla, la que detectará un meterpreter reverse_tcp.

Tras un poco de investigación, me doy cuenta de que cuando genero el payload usando msfvenom, Metasploit usa una plantilla por defecto para crear el ejecutable. Dicha plantilla contiene metadatos que mostramos a continuación.

Podemos observar los metadatos del payload usando la herramienta exiftool. Aquí apreciamos que al generar el payload, Metasploit usa los campos Internal Name y Original Filename y les asigna el valor (ab.exe).

Con esta información podemos crear una regla que busque la cadena de texto “ab.exe” dos veces en el binario. Para una detección más efectiva, incluiremos las DLL’s necesarias para meterpreter.

rule Meterpreter_rev_tcp
{
        meta:
                descripcion = "Meterpreter reverse TCP"
        strings:
		$metadatos "ab.exe" wide nocase
		$dll1 = "MSVCRT.dll" nocase
		$dll2 = "KERNEL32.dll" nocase
		$dll3 = "ADVAPI32.dll" nocase
		$dll4 = "WSOCK32.dll" nocase
		$dll5 = "WS2_32.dll" nocase
		$dll6 = "ntdll.dll" nocase
        condition:
              #metadatos == 2 and all of ($dll*)
}

Ya hemos visto lo fácil que es crear reglas para detectar amenazas específicas. El verdadero desafío es crear reglas más genéricas que detecten nuevas amenazas.

Dejando de lado todo lo bueno de YARA, una de las cosas que me generan más dilema es el hecho de compartir las reglas con la comunidad. Esto es debido a que si las reglas son públicas, un atacante puede acceder a ellas para modificar el binario y que no sea detectable. Ésta es la razón principal por la que sospecho que mucha gente que se dedica a la investigación de malware no publica sus reglas YARA.

Para el siguiente post, usaremos nuestras reglas YARA con Volatility sobre un volcado de memoria para crear un escenario de investigación forense más realista.