Cómo bloquear la nueva ola del malware Emotet escondida en formato XML (y cómo funciona)

Está en las noticias: Emotet es la amenaza de moda que se propaga con éxito a través de modelos de finales de los 90 (sí, en 2019). Sí, con macros. Emotet es complejo de explicar, pero iremos por partes. Últimamente ha tomado una decisión inteligente: seguir con las macros pero en un formato de Word relativamente poco conocido (efímero y en desuso) pero al que por supuesto Microsoft sigue dando soporte desde hace tres lustros. Esto le está proporcionando un gran éxito pero (y esto es lo bueno) también un punto débil.

Emotet es un tipo de malware muy famoso últimamente. Si en algún momento has visto un documento con la pinta de la imagen anterior, y le has hecho caso, probablemente estarás infectado. Emotet (cómo casi todo el malware) tiene dos componentes importantes: cómo se propaga y el malware en sí. El malware en sí es una especie de troyano bancario, decimos «especie» porque es complicada su clasificación, cambia con el tiempo y las campañas. Robará información sensible, permitirá enviar spam desde el infectado, recibirá comandos de un command and control para realizar acciones… En definitiva, lo más acertado es que si alguien se infecta con Emotet, el malware tendrá el control del equipo si puede elevar privilegios, con todo lo que ello conlleva. Sus creadores no han optado por el ransomware, y por tanto pasa bastante desapercibido hasta que es demasiado tarde.

Pero aquí nos interesa cómo se ha ido esparciendo y llegando a sus víctimas con el tiempo. Ha pasado por varios formatos durante los años que lleva activo, pero casi siempre ha sido a través de archivos adjuntos en el correo, PDFs y, desde hace algún tiempo, con documentos Word y Excel.

Lo interesante es que en los últimos tiempos, ha migrado a un formato muy poco conocido de Word, se trata de Microsoft Office XML. No lo confundáis con Office OpenXML, que es el formato «más habitual» y que típicamente es un ZIP con muchos XMLs dentro con extensión .docx. Microsoft Office XML, por el contrario, es puro XML, plano, se activó en Microsoft sobre 2002, cuando querían abandonar su formato propio, pero todavía no estaban seguros de adoptar el estándar que tomaron en 2007. Su vida, por tanto, fue efímera y de poco éxito, pero ahí sigue: todos los Office lo soportan aún.

Antes de seguir con Emotet, demos un repaso a la historia de los formatos usados por Office y sus macros en VBA. Visual Basic for Applications es el lenguaje sobre el que se crean las macros en Office que apareció en 1993. Está relacionado con Visual Basic, en el sentido de que necesita de su motor para ejecutarse, pero no es independiente: debe correr dentro de otra aplicación que contenga el código, e interactuar con otras a través de objetos OLE Automation (un IPC interno de Microsoft). VBA se compila en P-Code (también usado en Visual Basic), un sistema propietario de Microsoft que permite su decompilación al formato original en el que fue escrito el código. Una vez compilado, se almacena en el documento de Office correspondiente como un flujo separado encapsulado en un objeto OLE o COM.

Dependiendo de la versión del formato Office usado, este objeto puede encontrarse incrustado en el documento, o como fichero separado. Desde 2007, existen formatos muy diferentes de documentos Office que se pueden usar, aunque algunos son mucho más populares que otros.

• El formato propio de Microsoft anterior a 2007 con extensiones .doc y .xls (formato «clásico»). Los formatos binarios anteriores a 2007 son en realidad un objeto OLE en sí mismos y en cierta manera se asemejan a un sistema de ficheros simplificado. En estos formatos, las macros se almacenan en un directorio «Macro» que contienen a su vez el objeto COM.

• Basadas en formatos Open XML posteriores a 2007 cuyas extensiones son .docx y .xlsx. Estos formatos son en realidad objetos ZIP, que contienen el mismo objeto COM a modo de macro, además de una configuración estructurada fundamentalmente en XML. También existe el formato con extensión .docm, que se creó para indicar que el fichero realmente contenía macros y diferenciarlos claramente de los .docx.

Pero antes de 2007 y después de 2003 se creó este formato extraño XML propietario solo de Microsoft, como ya hemos explicado, y que ahora es aprovechado por atacantes. Hemos dicho que es un formato «plano», pero ¿qué pasa si los atacantes quieren incrustar macros compiladas en él? Pues muy sencillo, se añade el dato: w:macrosPresent=»yes» en el formato, y se codifica todo en base64 dentro. Ejemplo con esta macro incrustada en un documento XML plano.

Para analizar esta macro, podemos agarrar todo el contenido en base64 y copiarlo a un fichero. Lo decodificamos y el binario resultante estará comprimido con ZLIB. Eliminamos la cabecera hasta el carácter 0x78.

Y a su vez este resultado, se puede «deszlibear» con este simple código:

Y outfile.txt será ya finalmente un documento MS «clásico» en sí mismo (objeto COM), que contendrá las macros.

Hemos hecho un experimento con pocas muestras, pero interesante. Tras tomar muestras en formato XML, las hemos pasado a .doc, .docm (a .docx ya no lo permite Office si tienen macros) y, efectivamente, el formato influye en la capacidad de detección en estático. No todos los motores manejan bien todos los formatos, o al menos no con tanta habilidad. Aunque no hemos realizado el experimento completo con demasiadas muestras, sí que algo les influye. Por ejemplo, en la reciente muestra de la imagen, se trabaja con un XML plano que representa un archivo Excel. Combina compilación .NET y JavaScript y, a pesar de lo evidente de la infección en el tramo final, este tipo de fichero es muy poco detectado en estático.

Pues existen varias formas, por supuesto las típicas (y por tanto menos efectivas) de utilizar antivirus (que ya se hace, pero evidentemente no es suficiente) junto con las más complejas para bastionar el sistema (privilegios, permisos, etc). Pero una fórmula sencilla es simplemente presuponer que es bastante improbable que alguien con intenciones legítimas comparta un fichero en este formato, así que bloquearlo tampoco supondrá ningún trauma. En el peor de los casos, el que lo envía podrá volver a hacerlo en cualquier otro formato si se le solicita. Tenemos varias formas, una, con el nunca suficientemente ponderado gpedeit.msc

Otra, desde las opciones de seguridad del propio Word, en el centro de confianza.

En el fondo, esto modifica esta rama del registro:

Aunque el CLID será diferente en cada máquina. Si lo sabéis y queréis realizarlo con un sencillo script en PowerShell, esta es la fórmula:

New-Item -Path «HKCU:SoftwareMicrosoftWindowsCurrentVersionGroup Policy Objects{xxxxxxx-xxxx-xxxx-xxx-xxxxxxxxxx}Usersoftwarepoliciesmicrosoftoffice16.0wordsecurityfileblock» -Force | New-ItemProperty -Name «wordxmlfiles» -Value 0

Y por supuesto, no olvidéis que podéis bloquear las macros totalmente en tres sencillos pasos.