Hace unos días apareció en nuestros sistemas de detección un documento RTF a través de una regla bastante genérica que tenemos “para ver qué pilla”. Se trata de una regla que muchas veces nos genera falsos positivos, pero la cantidad es perfectamente asumible por los buenos resultados que nos da cuando acierta.
Llama la atención que siendo del típico correo tipo “Purchase Order”, hubiera pasado por varios filtros sin haber levantado sospechas. Tratándose de una amenaza genérica, no dirigida contra nadie en concreto, parece raro que estén utilizando alguna técnica o exploit novedoso.
En un primer vistazo rápido en estático no parece haber nada raro. El archivo tiene la típica ofuscación con caracteres de “espacio en blanco” en su interior, que, aunque simple, es efectiva para ocultarse ante la búsqueda de firmas. Dentro contiene un objeto identificado como ‘tFsqXa3iGNVxvyKH5LKGet0hQKeCl‘. Nada concluyente. La socorrida herramienta ‘strings’ tampoco es de mucha ayuda. Lo único que se puede identificar rebuscando algo más es una shell dentro de este último objeto tras extraerlo.
A todo esto, el documento ya era del dominio público, pero en el momento del análisis ningún AV me daba pistas sobre qué vulnerabilidad/funcionalidad de la que podría estar aprovechándose.
Del objeto contenido en su interior tampoco he podido obtener mucha más información en VT.
Paso entonces a comprobar si un análisis dinámico puede darme alguna pista para orientarme, porque no sé de dónde me vienen los tiros. Abro el documento y ciertamente veo que se genera una petición de red sospechosa… y en Process Monitor ha aparecido algo que me es familiar:
“EQNEDT32.EXE”, el ejecutable encargado de procesar las ecuaciones en los documentos de texto. ¿Se trataría de alguna de las vulnerabilidades que abusan de este viejo ejecutable tanto tiempo olvidado por Microsoft? Resulta raro que teniendo diferentes reglas para detectarlo no haya saltado ninguna. Reviso las reglas de los CVE-2017-11882 y CVE-2018-0802 para comprobar si alguno de los IOC que hay en ellas aparece aunque sea suelto. NADA.
Office tiene que saber de alguna manera que el objeto dentro del RTF tiene que abrirlo con “EQNEDT32.EXE”. Pero no encontraba de ninguna manera la típica cadena “Equations” que aparece en casi todos los documentos maliciosos de este tipo. Habrá que entrar un poco más a fondo en la estructura del documento para encontrar esos bytes que le indican a Word que tiene una ecuación ante sí.
Entiendo que no tengo que meterme a pelear con RTF, que en este caso actúa como un simple “envoltorio”, sino que mis cuentas las he de saldar con el objeto que se encuentra en su interior. Extraigo el objeto con ‘rtfobj’ de las Oletools y, según el comando ‘file’, se trata de un “Composite Document File V2 Document”, con la conocida firma “D0 CF 11 E0 1A 1B 1A E1”.
Tras buscar un poco llego a un documento del proyecto OpenOffice donde tienen documentada la estructura de este tipo de objetos. Comienzo a empaparme de su contenido. Al llegar a la octava página es hora de abrirlo a doble pantalla junto al editor hexadecimal destripando el objeto que se encontraba dentro del RTF. Por el momento no aparece nada interesante, sólo cómo está organizada la información en su interior.
Sigo avanzando páginas hasta llegar a la sección “Directory Entry Structure” (pág. 15), donde aparece al fin la sección dedicada a los objetos almacenados en el documento. El documento contiene un único objeto en la dirección 0x400. Voy entrada a entrada comprendiendo el significado de cada una hasta que llego al “Unique identifier”, que se encuentra en el offset 80 (0x50 en hexadecimal). Este identificador parece no referirse a la estructura de la información dentro del documento, sino que podría estar relacionado con el contenido del propio objeto en sí. Desconocía si era un identificador único generado aleatoriamente para, por ejemplo, unir distintos bloques separados en el documento, o si bien estaba relacionado con la información almacenada en su interior.
Pruebo suerte e invoco a San Google buscando estos 16 bytes tal y como aparecen en el objeto. Aparece solamente un único resultado. Se trata de unas reglas de ClamAV que parecen estar relacionadas con documentos maliciosos, concretamente con CVE-2017-11882 y CVE-2018-0802. Parece que voy por buen camino.
Pero me resulta raro que solo aparezca esta referencia en Google. Se me ocurre entonces buscar los primeros 4 bytes suponiendo que se encuentran en little endian “0002CE02”… et voilà! Ahora tengo más suerte y encuentro muchos más resultados, siendo el primero de ellos una entrada de Microsoft que habla sobre cómo deshabilitar el editor de ecuaciones en Office:
https://support.microsoft.com/es-es/help/4055535/how-to-disable-equation-editor-3-0
Parece ser que el CLSID {0002CE02-0000-0000-C000-000000000046} está relacionado con el editor de ecuaciones. De ahí que se utilice para deshabilitarlo a través de una entrada de registro.
¿Será este identificador el que utilice entonces Word para comprobar el tipo de objeto? Probémoslo viendo qué ocurre si cambiamos este identificador en el documento. Me voy al .doc original y modifico la zona de memoria donde aparece “02CE0200” y cambio una letra cualquiera.
En este caso he cambiado la tercera letra, una ‘C’, por una ‘D’. En la imagen no se ven los bytes “0002DE02” juntos debido a la ofuscación introducida, que intercala espacios en blanco (0x20), tabuladores horizontales (0x09) y saltos de línea (0x0A y 0x0D) que posteriormente son omitidos por el intérprete de RTF.
Con este único cambio, al abrir el documento con Word, la vulnerabilidad ha dejado de ser explotada, ya que no identifica el objeto como una ecuación.
Tengo entonces ya un buen indicador para comenzar a mejorar la detección de este tipo de vulnerabilidades. Esta regla Yara puede ser una buena primera base sobre la que empezar a trabajar identificando documentos que contengan ecuaciones que puedan llegar a intentar explotar vulnerabilidades en el viejo editor de ecuaciones de Office.
Good job ;).