Cuando una ñapa puede complicarte la vida: Emotet y lo que el sysadmin desconoce

Hola a todos. Sé que hace mucho tiempo de mi anterior entrada, pero han ido surgiendo cosas, temas personales y familiares que al final te alejan de lo que quieres hacer y los días se escapan como los segundos de un reloj.

Pero 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, en mi limitada experiencia en seguridad, me parece una buena cabeza de playa para un APT.

Voy a dividir el post en tres partes:

1. Resumir el entorno alrededor del correo electrónico.
2. Hablar de los adjuntos maliciosos en correos electrónicos y describir superficialmente dos de las variantes (que me he encontrado) que nos llevan al ataque actual.
3. Ver qué medidas de seguridad vulneran y por qué puede ser tan efectivo.

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

Así que vamos a por ello. Comencemos con una nueva entrada de Soportando y Sysadministrando.

 

1. El entorno de correo electrónico.

Da igual la empresa en la que estés, pocos sistemas hay tan ubicuos como el correo electrónico. Tan universales y a la vez tan desconocidos para muchos, así que empecemos poniendo las fichas sobre la mesa contando, por encima y de forma muy general, cómo es una arquitectura de correo electrónico.

Vamos a definir cuatro elementos del rompecabezas que vamos a ver:

• Checkpoints externos: sistemas empleados para verificar el correo entrante y saliente al exterior. Esto nos permite definir un entorno interno y externo (intranet e internet) en función de en qué red se mueve el correo, y establecer medidas de seguridad (como antimalware, antispam, antivirus, políticas sobre adjuntos...) diferentes para ambos entornos.
• Servidores de correo: ya sea un Zimbra, un Exchange, un Postfix... El sistema que se encarga de gestionar el correo a nivel de servidor y de establecer políticas sobre el correo dentro de la intranet.
  
• Relays: si tu organización es grande seguramente necesites unos cuantos nodos para encaminar el correo y para descargar al servidor principal, haciendo funciones de caché, por ejemplo.
  
• Terminales: el programa o sistema que emplee el usuario final para recibir el correo, sea Outlook, Thunderbird, webmail...
  

Esto nos permite definir cosas como redundancia, alta disponibilidad... Que vamos a dar por supuestas porque en este caso no son relevantes, ya que el ataque no les afecta. También es posible que hayas metido varios de estos roles en la misma máquina, pero vamos a mantener esta división, por el bien del argumento (y porque lo hace más interesante y, en mi caso, próximo a la realidad). Yendo a un caso sencillo, nuestra arquitectura completa tendría un aspecto similar al de la imagen:

Imagen 1: arquitectura general de un servicio de correo con seguridad perimetral y relays de distribución interna. Nótese que los distintos relays pueden definir zonas de correo diferentes. Fuente: elaboración propia usando Diagrams.net

Esto significa que si quieres mandar correo dentro de una zona no tienes que llegar hasta el servidor principal, y salvo que mandes o recibas correo del exterior no vas a tener que cargar con todas las comprobaciones y la ralentización que supone pasar el checkpoint externo.

Con este diagrama, tenemos cinco puntos donde podemos aplicar seguridad, y cinco etapas que el atacante debe superar para lograr su objetivo:

1. Checkpoint externo.
2. Servidor de correo.
3. Relays.
4. Sistema operativo del terminal.
5. Usuario final.
   

Que securizar el correo es uno de los mayores quebraderos de cabeza de nuestro gremio no es sorpresa para nadie: hay que ser lo suficientemente abierto para que el correo funcione pero lo suficientemente restrictivo para que no se cuele lo que no debe. La única forma de estar seguro es cortar la luz a todos los enrutadores de la empresa, pero como no es una opción, se trata de llegar a soluciones de compromiso, y a responder, en la mayoría de los casos, de forma reactiva y con un plan de control de daños si las cosas se te escapan de las manos.

Habrá quien se pregunte por qué figura el usuario en esta lista: porque es el usuario el que al final hace clic sobre el adjunto, el elemento que desencadena la infección, la última línea de defensa cuando todo lo demás no ha sido suficiente. No importa cómo diseñes tu aplicación o tu procedimiento sino cómo lo utiliza el usuario final, y vamos a ver cómo este nuevo ataque aprovecha precisamente eso. 

 

 2. Los antecedentes: malware en correo electrónico.

Que los adjuntos de correo electrónico son El Mal lo sabemos todos, especialmente estos días con las felicitaciones de Navidad: que levante la mano el sysadmin que no haya tenido alguna movida estos días a cuenta de las felicitaciones y/o que haya tenido que sacar su dominio de alguna lista de spam.

Enviar malware por correo no es algo nuevo: el virus Bubble Boy, considerado el primero que usaba dicho mecanismo, es de 1999. Lo que sí ha cambiado desde entonces es el mecanismo, y mucho. El antecedente más cercano a lo que os voy a contar es el "malware de factura de Endesa": un correo adjuntando un cryptolocker ofuscado como PDF urgiendo al usuario a pagar la factura lo antes posible, lo que desencadena la infección.

Es la clase de ataques que parecen una tontería hasta que te toca currar en una gestoría que se dedica, entre otras cosas, a pagar facturas a Endesa, como era mi caso entonces. Que desde entonces venere los antivirus como los salvadores de la Humanidad en general y de los microinformáticos en particular es un efecto secundario sin importancia.

La cuestión es que si tu modo de vida se basa en infectar ordenadores, no dejas que un antivirus te detenga. Tienes que comer y los caseros no suelen aceptar que les pagues el alquiler en abrazos, así que buscas alternativas.

Y de repente descubres las macros de Office. Y te curras una macro dentro de un Excel que llame a un servidor remoto para bajarse un ejecutable donde haces la magia que antes hacías con el ejecutable ofuscado de PDF.

Es un plan sólido, hasta que el sysadmin se da cuenta y bloquea todos los correos que lleven adjunto un documento de MS Office con macros embebidas. Porque, no nos vamos a engañar, conocemos muy pocos usuarios que sepan y usen macros de forma regular.

Pero entonces el atacante se acuerda de algo que hizo cuando empezó a trabajar en informática, o que le han contado, o que ha leído en algún foro. Es un detalle sin importancia, pero es la vuelta de tuerca que necesita para seguir usando exactamente el mismo ataque. Y no sólo eso, sino que puede hacer que el usuario baje la guardia y esté más dispuesto a ejecutarlo, aunque le hayas dado cursos para detectarlo porque usas su forma de trabajar, sus procedimientos del día a día para que lo haga.

Y se sienta un rato con sus notas, sus apuntes y su laboratorio de pruebas y se da cuenta de que esa solución, tan simple que no se ve por evidente no sólo le resuelve la descarga, sino que le permite vulnerar gran parte de la seguridad perimetral sin tener que hacer nada más. Con un poco más de trabajo, incluso pasar desapercibido.

Pero, ¿cuál es esa solución mágica?

Comprimir el documento con contraseña y adjuntar dicha contraseña en el cuerpo del mensaje.

No tiene que cambiar casi nada, sólo la plantilla del correo que está mandando para añadir la contraseña y un par de líneas más al script que genera el spam para comprimir el adjunto antes de agregarlo.

Oigo las risas a través del blog, así que vamos a explicar el problema.

 

3. Por qué el ataque puede ser (y es) tan efectivo.

Volvamos al diagrama de correo que hemos visto antes.

Paso 1: checkpoint externo

Muchas soluciones comerciales de fabricantes para nada prestigiosos como Cisco o HPE consideran por defecto que los archivos cifrados no se pueden analizar y, salvo que el administrador establezca una regla específica, los categorizan como dudosos aumentando un valor que llamaremos "peligro potencial", pero los dejan pasar si dicho "peligro potencial" está por debajo de cierto umbral (definible por el administrador). Ya que el resto del correo suele ser texto plano, el atacante sólo tiene que elegir desde qué dominios y con qué frecuencia se manda el correo para evitar las medidas de reputación de dominio y de spam, con lo que el correo atraviesa el checkpoint casi sin detenerse. ¿Has montdo DKIM, SPF y DMARC? Si el dominio desde el que viene el correo está bien montado pasarás esas comprobaciones, aunque se encuentre comprometido. ¿Tenías reglas para filtrar macros en el checkpoint? Su eficacia ha pasado a ser cero.

¿Cómo mitigarlo? Cuarentena preventiva para correos con adjuntos cifrados: tanto Cisco como HPE ofrecen servicios "nube" para análisis de archivos sospechosos. Si el correo se retiene el tiempo suficiente, puede enviarse para análisis y determinar si dicho adjunto demuestra ser peligroso.

¿Problema? Dicha comparación suele hacerse basándose en algún tipo de hash, por lo que cambiando la contraseña de cifrado hay que repetir el proceso. Y aunque hashearas todas las contraseñas de ese archivo, bastaría con añadir o quitar un caracter al contenido para volver a empezar como, por ejemplo, cambiando la URL que has embebido. Si tienes tantos servidores a tu disposición como se sospecha que tiene el grupo Emotet (que podrían rondar los miles), el problema no es trivial.

 

Pasos 2 y 3: servidor de correo y relays

Salvo que emplees medidas por zonas, la parada del correo en el servidor principal es momentánea antes de salir hacia su destino. Muchas empresas usan el mismo bloque de comprobaciones en los checkpoints externos y en sus servidores de correo, lo que abarata el coste de las soluciones y rebaja la complejidad de la infraestructura a cambio de reducir la seguridad (el eterno debate sobre cuánto debes gastar para estar seguro). El inconveniente es que comprobar el correo dos veces con el mismo paquete de medidas es como hacer ping a localhost: 127.0.0.1 contesta siempre, así que no sabes si puedes salir a internet.

¿Mitigarlo? Mediante integración: tanto los sistemas de checkpoint como los servidores de correo pueden reescribir las propiedades de un correo electrónico, así como añadir información adicional (como logs) invisible al usuario pero no al servidor ni al administrador: si el checkpoint añade información al registro del correo, es posible establecer una política en el servidor de correo o en los relays que retenga el correo, que fuerce una segunda comprobación o incluso que acepte el correo (dando la impresión de que se ha sobrepasado la seguridad exterior) mientras lo pasa a una cuarentena.

Esto se podría aplicar también en el checkpoint (y es lo preferible), pero si tienes relays puedes hacerlo así para añadir una segunda capa o si tienes tanto correo entrante que el checkpoint está saturando. Si tienes dos soluciones de seguridad (dos AVs diferentes, por ejemplo) podrías emplearlo para lanzar un segundo escaneado más profundo, fingir que estás dejando pasar el correo y dar apariencia de que el ataque es más efectivo de lo que realmente es: nadie actualiza sus herramientas si cree que funcionan.

Paso 4: sistema operativo del terminal

Ya hemos comentado que 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 ha hablado de ello aquí mucho mejor de lo que puedo hacerlo yo.

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.

Imagen 2: 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. Os 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.

Paso 5: el usuario y sus procedimientos

Vamos con la parte final, la más larga porque hay que hablar de bastantes cosas que se suelen pasar por alto, pero que en este caso me parecen más que importantes.

Sin embargo, y a pesar de todo lo que hemos dicho, el ataque no se ha producido todavía. Aún no ha pasado nada, pero como dijo John Goodman en "el gran Lebowski", estás a punto de conocer el dolor: tu usuario está a punto de abrir voluntariamente el archivo comprimido y ejecutar la bomba que va dentro. ¿Porque es estúpido? No. ¿Porque ha pasado de las formaciones para identificar correos maliciosos? Tampoco.

Porque tú le has enseñado que eso es lo que debe hacer o, mejor dicho, porque no le ha quedado alternativa para realizar su trabajo.

Rebobinemos para entender cómo puede pasar esto. Vamos a ver un caso que es el día a día de mucha gente: un usuario medio tiene que enviar digitalmente una documentación muy importante y sobre él pesa alguna variante del "o lo mandas ya o te vas a la calle".

El usuario no puede usar un FTP, tiene capados servicios como WeTransfer (que seguiría siendo una mala idea), la única manera de enviar esa documentación es por correo electrónico y no tiene procedimientos definidos para ello.

Pero es información confidencial, así que pide ayuda al microinformático o al de soporte, que seguramente llame a Sistemas para pedir consejo o ayuda y que recibirá la respuesta de "para un solo envío no merece la pena. Improvisa". Así que el informático recordará que se pueden cifrar los datos cuando los comprimes y le explica cómo hacerlo. El usuario adjunta el archivo, mete la contraseña en el correo y sale del paso.

Pero al día siguiente pasa lo mismo, y repite la operación; y al día siguiente, otra vez. Al cabo de una semana, lo que empezó como una ñapa se ha convertido en regla, la gente a su alrededor empieza a adoptarlo también, y ya no sólo envía correos así sino que también los recibe. Como está hasta las cejas de trabajo, automatiza el proceso de descargar el adjunto, buscar la contraseña y abrir el archivo casi sin mirar, porque leer el correo es sólo una parte pequeña de su trabajo.

Y así una "ñapa sin importancia" asciende a "puerta trasera para diplodocus" sin que nadie se dé cuenta.

Así llegamos al "momento cero" de la infección, con un usuario que ha hecho ni más ni menos que lo que hace todos los días, y puede sonar como exageración o caso extremo, pero he visto esta historia tanto en soporte como en operación.

¿Cómo solucionamos este problema? Dándonos cuenta de que no es uno sino varios a la vez y que cada uno de ellos tiene responsables diferentes:

1. Que no hay canales adecuados para enviar información confidencial: tras tantos años de LOPD y RGPD se sigue enviando información fiscal o sanitaria sin cifrar por correo electrónico. Es sorprendente la cantidad de sitios que hoy día mandan los resultados de analíticas o exámenes médicos en PDF sin contraseña, o empresas que mandan las nóminas escaneadas en el cuerpo del mensaje.
   
2. Que la formación en informática del usuario medio (y de sus jefes) es inexistente: y lo que es más grave, que a nadie parece importarle. Se arrastran formas de trabajar de las máquinas de escribir porque ni los usuarios ni sus jefes conocen las ventajas de las formas de trabajar que proporcionan los ordenadores, por lo que introducir mejoras en formación o de infraestructura son muy complicadas: puedes montar un FTP y securizarlo, pero si el usuario no sabe utilizarlo o lo considera un inconveniente, el FTP no sirve para nada. Viví esa historia estando en Soporte.
   
3. Que el trabajo de Soporte/Microinformática no se considera parte de Sistemas ni de ninguna otra rama de la informática. Los técnicos de soporte improvisan porque la mayoría de las veces están convencidos de que no tienen apoyo, que están solos frente a lo que usuarios, sysadmin y developers puedan echarles encima, y suelen tener razón. Al estar "fuera" sus problemas no se consideran importantes, por lo que echan mano de soluciones "creativas" sin comunicarlo a nadie, porque esa labor se considera de tan bajo nivel que, en fin, no documentamos despliegues de servidores, como para documentar cómo envía correo un departamento de tres personas
   

Estos tres problemas pueden resumirse en que los informáticos nos hemos olvidado, en mayor o menor medida, de lo que en broma llamamos la "capa 8 del modelo OSI", la "interfaz silla-teclado" o el usuario final. Y sería un problema menor si en el camino no nos hubiéramos olvidado también de los compañeros que lidian con esos usuarios, porque Soporte hace ese trabajo que ninguno queremos hacer: hablar con los usuarios, ver qué problemas tienen y poner a punto sus equipos.

Lo que también se nos ha olvidado es que Soporte puede ser (y es) las manos y los ojos de Sistemas dentro de la empresa: conocen a los usuarios, los problemas habituales con las aplicaciones, esos procedimientos que nadie ha apuntado, hablan con los técnicos de mantenimiento y se enteran de lo mismo que el personal de limpieza porque en muchos casos cuentan con una libertad similar.

Sin embargo, el problema con este ataque de correo es uno de esos procedimientos que Soporte conoce y que posiblemente haya puesto en marcha porque se encuentran fuera de Sistemas.

¿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. Y si el argumento no te convence, recuerda el refrán: "ten amigos hasta en el Infierno".

4. Resumen y despedida

Este ataque se caracteriza por un cambio "sencillo" de algo que conocíamos y que tiene consecuencias importantes. Creo que obligará (o debería obligar) a repensar la forma en la que diseñar la seguridad, al implicar a gente que normalmente se ha quedado fuera del proceso. Reescribir una regla en un firewall es sencillo, pero cambiar cómo se hacen algunas cosas cuesta más.

Sobre Soporte, es posible que pienses "en mi empresa no es así", y puede que tengas razón, pero la inmensa mayoría de los que hemos pasado por Soporte contamos las mismas historias y guardamos recuerdos similares. Es posible que tu empresa sea una excepción, pero hay muchas que no y aunque mi mensaje va dirigido a los que trabajan en ellas, podría ser buena idea comprobar que me equivoco... Por si acaso.

Por último, y antes de despedirme, quiero dar las gracias a una serie de personas:

• A Cristian Borghello (@SeguInfo) por colgar lo que considero mi "alerta temprana" y por lo que hice saltar las alarmas en mi oficina.
• A Gabriel Marti (@gmarti), por su investigación y gran explicación sobre cómo funciona el ataque con macros.
• A Erica Aguado (@erica_aguado), por haberse encontrado el bicho e incitado a Gabriel a escribir el artículo.

Y con esto ya me despido. Si habéis llegado al final, muchas gracias por leerme, y si queréis hacer comentarios, avisarme de erratas o enmiendas, podéis hacerlo abajo o escribirme por Twitter (@Tach80).

Hasta entonces, que paséis felices fiestas y desearos que 2021 no sea la versión 2 de este año que vamos a dejar. ¡Nos vemos!