Emotet y lo que el SysAdmin desconoce

Hoy vengo a contaros una movida de las que me gustan: cómo se han unido técnica, habilidad, procedimiento e ingeniería social para hacer bypass a casi todas las medidas de seguridad que podamos tener montadas en la empresa, usando el correo electrónico. Es algo que estoy viendo en el trabajo (y que puedo contar porque es público) y algunas cosas sueltas que parecen no tener sentido hasta que las unes.

Y es sobre lo que parece ser la nueva (y más elaborada) campaña de spam lanzada por la botnet Emotet, una vieja conocida por todos los que trabajamos leyendo logs de sistemas de correo y que es una buena cabeza de playa para un APT.

Y como no puede ser de otra forma, lo voy a contar desde el punto de vista de Operación y de la forma más general posible: no diré qué hay que hacer en un entorno concreto pero sí daremos algunos conceptos que se pueden utilizar a la hora de enfrentar este problema u otros similares en el futuro.

¿Por qué documentos Word?

Podría mostrar una larga lista de argumentos, pero uno de los principales es por su facilidad de insertar macros (un script de código) que permite ejecutar acciones sin intervención del usuario.

Word ha ido cambiando con los años, y con ello también ha variado el formato de los archivos que genera por defecto. Las versiones anteriores hasta Word 2003 utilizaban la extensión ".doc" que era un formato binario que también fue cambiando y evolucionando con los años.

Las versiones actuales, desde Word 2016, utilizan la extensión ".docx" y por lo tanto un formato diferente al binario anterior. En realidad, es un conjunto de archivos y carpetas en formato "xml".
Con un editor hexadecimal se puede comprobar la firma de este archivo y veremos que coincide con la de los archivos ZIP que es 50 4B 03 04. A estas firmas de los diferentes formatos de ficheros también se las conoce como "magic numbers" o "magic bytes".

Emotet en documentos de ofimatica

El desencadenante es una macro de Office, pero que el paso "delicado" es la llamada al servidor remoto porque es donde se inicia el ataque. Sobre el ataque en concreto, Gabriel Marti habla de ello aquí.

Lo que voy a contar tiene dos vertientes: la que ha descrito Gabriel (que es la que vemos desde septiembre de 2019) y una que me he encontrado, que tiene un paso previo más y que, aunque no he lidiado personalmente con ella, he visto lo suficiente para lo que os voy a contar.

El documento siempre contiene una macro de Office. En el caso de Gabriel, la macro llama directamente al servidor remoto para descargar el malware, y en el caso que he visto yo, primero lanza un script de PowerShell que es el que se conecta al servidor remoto y descarga el malware.

En ambos casos, mitigarlo podría ser tan sencillo como deshabilitar las macros de Office: sin macro no hay llamada. Personalmente, no he encontrado un sitio donde las macros se utilicen a menudo, no digamos enviar un archivo así por correo, así que deshabilitar las macros por defecto al instalar Office (o por política de dominio) me parece una buena práctica al margen de este ataque.

El script de PowerShell ya es más complicado de mitigar: por defecto, la política de ejecución de scripts de PowerShell es "RemoteSigned" para servidores, "Restricted" para no servidores y "Unrestricted" para aquellos sistemas operativos que dependan de Active Directory pero no sean Windows, pero al haber definido "scopes" para la ejecución de scripts es posible cambiar las políticas de forma escalonada y obtener permisos suficientes para descargar el software malicioso remotamente sin necesidad de escalar privilegios.

Políticas de PowerShell por defecto. Existe un scope llamado CurrentUser que se puede cambiar sin privilegios y permitiría ejecutar ese código sin escalar. Documentación aquí (Microsoft)

Mitigarlo en este caso sería subir las restricciones de todas las máquinas que tengas en dominio a, por ejemplo, "AllSigned". La buena noticia es que no hay que hacerlo a mano, que se puede hacer mediante política de grupo. Dejo el procedimiento aquí.

La alternativa es restringir completamente el acceso a PowerShell, como se describe aquí, pero me parece excesivo, ya que pierdes la capacidad de automatizar procesos en máquinas del dominio.

El problema que tenemos en este caso no es técnico, sino de mentalidad: en muchos sitios se considera que los puestos de usuario son problema de Soporte, y lo que hace Sistemas es aplicar políticas de dominio para actualizaciones y que Active Directory sirva sólo como LDAP. En pocas palabras, se monta AD para automatizar lo que se puede de Soporte pero no como herramienta de gestión (ni de seguridad), por lo que medidas como limitar o restringir PowerShell no se consideran, dejando la puerta abierta a ataques de este tipo.

¿Cómo arreglar esto?

En primer lugar, tendrás que auditar tus procesos para saber si alguno de los departamentos es vulnerable a este tipo de ataque de ingeniería social. Cómo hacerlo depende de cada empresa, pero hablar con Soporte puede ser un buen paso en la dirección correcta, no sólo para obtener información sino para recuperar esa relación que debería haber entre Sistemas y Soporte: ningún líder de equipo que se precie renunciaría voluntariamente a las posibilidades de tener manos y ojos fiables sobre el terreno.

¿Quieres que el problema no se te vaya de las manos, o que cuando lo haga puedas tener la situación bajo control? Habla con Soporte. Reúnete con sus técnicos, explícales el problema que hay de forma clara y pídeles ayuda: los usuarios son su terrreno, uno que conocen mejor de lo que crees y en el que se mueven con la misma facilidad que tú en una consola. Pueden localizar los departamentos vulnerables y ayudarte a encontrar una solución que funcione con los usuarios. Incluso aunque sólo prevengan a los usuarios del peligro ganas tiempo, y si por casualidad se la cuelan a un usuario, el técnico puede aislar ese equipo en cuestión de minutos, reduciendo el peligro.

Si alguien es capaz de meter PowerShell en una macro de Office y enmascararlo para que el usuario ni siquiera se plantee lo que está haciendo, su objetivo no va a ser comprometer un equipo de un usuario de contabilidad, sino controlar todos los niveles de tu infraestructura que pueda (APT), y ese correo es el primer paso.

Yo no me dedico a la seguridad de forma profesional (aprendo "lo que necesito" y "sobre la marcha"), pero contra un APT querría tener toda la ayuda que fuera posible, y mi experiencia en Soporte (cinco años) me dice que se puede ser una puerta trasera para estas cosas o un sistema de alerta temprana y cortafuegos, y que la diferencia en estas situaciones depende de la confíanza que creas que hay en ti.

Así que la solución en este caso no es técnica, sino humana. No se trata de meter más antivirus o más seguridad, sino hablar con los que tienes alrededor y considerarlos como lo que son: técnicos que pueden arreglar un problema.

¿El problema? Que estas cosas llevan tiempo. Es muy probable que no obtengas un resultado espectacular, pero es el primer paso para descubrir muchos problemas que tienes y que desconoces, y tener disponible un equipo que no sólo te ayudará en estas situaciones, sino que podría evitar algunas de ellas en el futuro.

Fuentes: Soportando y SYSadministrando | Gabriel Marti

Suscríbete a nuestro Boletín