Ir al contenido principal
Blog de Tanium

Robar correos electrónicos, déjame contar las formas

El ataque informático al Comité Nacional Demócrata, del que se ha informado recientemente, ha vuelto a poner de relieve una forma de robo de datos increíblemente habitual: las intrusiones dirigidas a los correos electrónicos. La reacción instintiva ante este tipo de violaciones de seguridad suele consistir en recomendar medidas de control como el cifrado de mensajes y la autenticación de dos factores. En realidad, prevenir, detectar y responder a estos ataques resulta mucho más complicado. Una red corporativa típica ofrece un sinfín de oportunidades a los atacantes para sustraer correos electrónicos, ya se trate de una acción muy específica que afecte a un número reducido de usuarios o de un intento de recopilar datos de forma masiva a lo largo del tiempo.

A lo largo de los últimos siete años, he colaborado con numerosas organizaciones que han perdido correos electrónicos confidenciales durante ataques selectivos. En esta entrada del blog, voy a abordar varias técnicas habituales que he observado que utilizan los atacantes, analizaré el impacto de la autenticación y el cifrado, y destacaré las formas en que Tanium puede ayudar a detectar y responder a estos métodos.

Supuestos subyacentes

A efectos de esta entrada, partiremos de una serie de supuestos que considero «requisitos mínimos» para cualquier intrusión selectiva en un entorno Windows. En primer lugar, dejemos claro que la organización afectada utiliza Microsoft Exchange, que sigue siendo la plataforma de correo electrónico empresarial más extendida. Supongamos también que el atacante ya ha conseguido acceder a la red interna de la víctima y que, por lo tanto, puede actuar desde al menos desde uno de los siguientes puntos estratégicos:

  • Acceso a través de un navegador a un servidor de correo web accesible desde el exterior, como Outlook Web Access
  • Una vía de acceso a los servidores internos de Exchange a través de: (1) sistemas que ya hayan sido infectados con una puerta trasera dentro de la misma red interna, o (2) una VPN comprometida u otra solución de acceso remoto
  • Acceso no autorizado a una estación de trabajo de un usuario final que pertenece a una persona objetivo cuyos correos electrónicos son de interés

Por último, daremos por hecho que el atacante ha conseguido acceder al menos a uno de los siguientes tipos de credenciales:

  • Una cuenta con privilegios de Active Directory perteneciente a un administrador de Exchange o de dominio
  • Una cuenta de administrador local común que puede reutilizarse para el desplazamiento lateral entre los ordenadores de las víctimas
  • Una cuenta de dominio sin privilegios perteneciente a una persona objeto de investigación cuyos correos electrónicos son de interés

Teniendo esto en cuenta, repasemos algunas situaciones habituales.

Los atacantes suelen tener como objetivo Outlook Web Access (OWA)

Los atacantes suelen centrar sus ataques en Outlook Web Access (OWA) durante la fase posterior a la intrusión, es decir, una vez que han logrado sustraer las credenciales. Es especialmente fácil acceder a OWA si no requiere autenticación de dos factores o si no se encuentra detrás de una VPN que la exija. Una vez que se ha sustraído una cuenta de dominio —o todas las cuentas de dominio—, solo hay que iniciar sesión como cualquier usuario normal. Detectar esta actividad a gran escala en una gran organización multinacional puede resultar complicado, sobre todo si se tiene en cuenta que el atacante puede utilizar el acceso a través del navegador desde cualquier dirección de origen o a través de cualquier punto de enlace que tenga a su disposición.

Aunque el correo web esté protegido por una VPN, puede seguir estando expuesto a un atacante que haya logrado introducirse en la red interna. Los atacantes suelen comprobar si es posible acceder a la instancia del correo web accesible internamente utilizando credenciales de dominio de autenticación de un solo factor. En tal caso, pueden utilizar malware de túnel para actuar a través de un host ya comprometido con una puerta trasera y autenticarse como el usuario de interés.

¿Serviría de algo el cifrado?

Si la organización utiliza S/MIME con Outlook Web Access, solo se puede utilizar Internet Explorer para leer los correos electrónicos cifrados. Además, la clave privada necesaria para descifrar los mensajes debe estar instalada en el almacén de certificados del terminal local. Para ello, el atacante debe obtener acceso a la clave privada del usuario víctima o utilizar el acceso remoto al propio ordenador de la víctima para acceder al correo electrónico en su nombre. Ninguna de las dos cosas supondría un obstáculo significativo en caso de que se produjera una violación de la seguridad en todo el dominio.

Si la organización utiliza otros métodos de cifrado, como PGP, el atacante tendría que recuperar, una vez más, las claves privadas y las frases de contraseña del propio sistema del usuario afectado. En caso de que se produzca una violación de la seguridad en todo el dominio, puede resultar difícil impedir que un atacante acceda al sistema de un usuario concreto. Sin embargo, esto obliga al atacante a pasar de un comportamiento oportunista («Puedo conseguir el correo electrónico de Adam desde cualquier punto») a un comportamiento selectivo («En primer lugar, tengo que comprometer el sistema de Adam…»).

Conviene tener en cuenta que, a menudo, los usuarios optan por la vía más sencilla cuando utilizan un servicio como el correo web. Esto suele dar lugar al intercambio de mensajes sin cifrar cuando utilizan sus propios ordenadores u otros navegadores, lo que facilita el robo de datos, aunque el alcance se limite a un número más reducido de correos electrónicos.

¿Cómo pudo Tanium detectar esto?

Es evidente que una organización no tendría ningún control sobre un terminal controlado por un atacante que se utilizara para acceder directamente a OWA a través de Internet utilizando credenciales sustraídas previamente. Esto limita las fuentes de pruebas disponibles al tráfico de red y a los datos de registro de los propios servidores de correo. La centralización de los eventos de autenticación de Outlook Web Access en un SIEM, así como de los registros del servidor web, puede facilitar en gran medida las investigaciones a posteriori. En función de la arquitectura de la red, es posible que también tenga que correlacionar varias fuentes de datos para obtener la dirección IP de origen real de las solicitudes de correo web entrantes.

Tanium ofrece un paquete Copy Tools que permite recopilar y distribuir automáticamente los registros de los terminales a una ubicación centralizada para su ingesta y posprocesamiento. En casos anteriores, he colaborado con investigadores que lograron distinguir con éxito los accesos maliciosos de los legítimos a OWA en una cuenta comprometida, utilizando los agentes de usuario del navegador registrados en los registros de acceso, junto con la hora de acceso y las direcciones de origen.

Si el atacante accede al correo web a través de un sistema interno comprometido, esto proporciona muchas más fuentes de pruebas sobre los terminales utilizados para el «pivote». En función del método de acceso, Tanium ofrece sensores capaces de buscar entradas en el **Registro de eventos de seguridad** local**, el historial del navegador y así como de rastrear los procesos ejecutados , que incluyen el contexto del usuario para los eventos históricos. Por ejemplo, un atacante que utilice Internet Explorer a través de una puerta trasera en el sistema de un usuario infectado podría generar entradas en el historial del navegador bajo el perfil del contexto del sistema, en lugar de bajo el perfil de usuario del propio titular. Estas entradas suelen ser lo suficientemente anómalas como para justificar una investigación más exhaustiva.

Extracción de correos electrónicos del servidor Exchange con PowerShell

Dado que PowerShell tiene sus orígenes en la gestión de servidores Microsoft Exchange, no debería sorprender que se pueda utilizar para acceder a los buzones de correo de los usuarios y recuperar o enviar mensajes. He sido testigo de varias intrusiones en las que los atacantes utilizaron scripts maliciosos de PowerShell para recopilar direcciones de correo electrónico. Este método requiere una dependencia: la biblioteca Exchange Web Services (EWS)[1], que no se incluye de forma predeterminada con PowerShell.

En la práctica, el uso de EWS consiste simplemente en incluir un único archivo DLL, «Microsoft.Exchange.WebServices.dll», junto con el código de PowerShell. Una publicación muy útil en Stack Overflow[2] muestra lo fácil que resulta para un script recuperar mensajes de esta manera.

¿Serviría de algo el cifrado?

Si el atacante ejecuta el script de PowerShell desde el propio sistema del usuario afectado y bajo el contexto de su cuenta de dominio, tendría acceso a la clave privada almacenada en el almacén de certificados de Windows, necesaria para el descifrado S/MIME. Como se ha señalado anteriormente, si se utilizara otro método de cifrado, como PGP, el atacante tendría que seguir unos pasos adicionales para recuperar la clave y la frase de contraseña necesarias para ver los mensajes recuperados.

¿Cómo pudo Tanium detectar esto?

Tanium Trace registra de forma continua la actividad de las conexiones de red, junto con el contexto del proceso y del usuario correspondiente. Uno de nuestros paneles de control de detección utiliza el sensor Trace Network Connections para ofrecer una vista filtrada de todas las instancias de PowerShell que han establecido conexiones con los puertos 80 y 443. Salvo en el caso de los administradores de Exchange, este uso de PowerShell resultaría inusual en la mayoría de los sistemas de usuarios finales u otros tipos de servidores. Nuestros clientes suelen utilizar la funcionalidad «Grupos de ordenadores» de Tanium, junto con este tipo de paneles de control, para detectar este tipo de actividad maliciosa con mayor precisión.

Otro enfoque consistiría en comprobar la presencia o el uso de la biblioteca «Microsoft.Exchange.WebServices.dll» en los dispositivos finales. Los usuarios de Tanium pueden ejecutar los sensores « » (), «Index Query» () y « » () para buscar en todo el disco duro de todos los sistemas, en cuestión de segundos, esta biblioteca por nombre o por hash. Además, los sensores « », «», «Loaded Modules», «» y « » pueden identificar cualquier sistema que haya cargado esta biblioteca en memoria. Una vez más, los grupos de informática pueden aportar una perspectiva adicional para distinguir entre el uso previsto y el uso imprevisto de esta biblioteca.

Herramientas de la Interfaz de programación de aplicaciones de mensajería (MAPI)

MAPI/RPC es el protocolo estándar que utiliza Outlook para funcionar con los servidores Exchange. Dado que está documentado y disponible a través de diversas API, otras aplicaciones de Windows pueden utilizarlo. Por ejemplo, «MAPIGET.EXE», una de las utilidades destacadas en el informe 2010 de Mandiant sobre APT1, se conecta a los servidores de Exchange a través de MAPI y de credenciales NTLM sustraídas para recopilar los mensajes y los archivos adjuntos de una cuenta concreta. En los sistemas en los que se ha instalado Outlook, los lenguajes de scripting como VBS y VBA también pueden utilizar su espacio de nombres MAPI para interactuar con la bandeja de entrada y recuperar mensajes de correo electrónico, aunque están sujetos a restricciones que pueden variar en función de la versión de Outlook instalada y de su configuración.

Desde el punto de vista de la supervisión de la red, tenga en cuenta que el uso de RPC por parte de MAPI hace que los clientes se conecten a los servidores Exchange utilizando una amplia gama de puertos de números altos, en lugar de un único puerto de servicio fijo. Si Exchange está configurado con la función «Outlook Anywhere», los clientes pueden conectarse a través de RPC sobre HTTPS en el puerto 443.

¿Serviría de algo el cifrado?

Muchas herramientas basadas en MAPI se limitan a recuperar los mensajes cifrados con S/MIME como el «archivo adjunto smime.p7m” ». Tal y como se ha señalado anteriormente en nuestros otros escenarios, si el atacante está actuando desde el propio terminal del usuario víctima y dispone de privilegios suficientes, puede acceder al almacén de certificados de Windows.

¿Cómo pudo Tanium detectar esto?

Los sensores « » (), «Established Connections» (), « » y « » () y «Trace Network Connections» ()  pueden generar resultados apilables que permiten a los analistas comparar de forma inmediata el nombre, la ruta y el hash de cualquier proceso que se conecte a direcciones de servidor Exchange y rangos de puertos. Los analistas pueden profundizar aún más en el análisis mediante , , «Trace Executed Processes» () y  para obtener las líneas de comando y el historial de cualquier evento sospechoso. El seguimiento de estos datos puede permitir a una organización detectar aplicaciones no autorizadas que intentan comunicarse con la infraestructura del servidor de correo electrónico.

Robo de archivos locales de buzones y archivos de Outlook

Casi todos los usuarios de Outlook conocen las funciones de modo sin conexión y de buzón de archivo de la aplicación. Desde el punto de vista de un atacante, estos archivos son como cualquier otro archivo del terminal: pueden copiarse, archivarse y transferirse mediante comandos nativos del sistema operativo o utilizando funciones comunes a muchas puertas traseras. Dos factores limitantes pueden ser el tamaño de estos archivos y si el usuario ha optado por protegerlos con contraseña.

¿Serviría de algo el cifrado?

Si ha leído hasta aquí, probablemente ya haya adivinado la respuesta. Si el atacante tiene acceso a los archivos de Outlook de la víctima en su propio ordenador, es probable que pueda acceder a cualquier dato almacenado en el almacén de credenciales de Windows o que utilice programas de registro de teclas u otras técnicas para obtener otras credenciales.

¿Cómo pudo Tanium detectar esto?

El sensor « » Trace File Operations permite crear una búsqueda filtrada o un panel de control que realice un seguimiento de la creación o modificación de archivos de buzones de Outlook en ubicaciones atípicas, o por parte de procesos atípicos. Del mismo modo, los sensores de Tanium — , , Index Query,y  — pueden buscar archivos de buzones de correo en reposo en toda la empresa.

Registro de pulsaciones de teclas y captura de pantalla

Cualquier programa malicioso que se ejecute con privilegios suficientes en un sistema infectado puede registrar todas las pulsaciones de teclas y capturar periódicamente el contenido de las ventanas o de toda la pantalla. Muchas de estas herramientas pueden configurarse para que solo recopilen datos que coincidan con los patrones definidos por el atacante o que procedan de aplicaciones específicas o de títulos de ventanas concretas. El contenido de cualquier correo electrónico que consulte el usuario final podría quedar expuesto de esta manera. Por supuesto, este método no resulta ideal si el atacante desea recopilar rápidamente un gran volumen de correos electrónicos, y su alcance es limitado: es necesario infectar el sistema de cada usuario víctima, y el malware puede capturar una cantidad significativa de datos irrelevantes con el paso del tiempo.

¿Serviría de algo el cifrado?

No. Si aparece en pantalla o se escribe, queda al descubierto.

¿Cómo pudo Tanium detectar esto?

Existen innumerables formas de implementar puertas traseras, registradores de pulsaciones de teclas, programas de captura de pantalla o de extracción de datos y otro tipo de malware relacionado; por lo tanto, no existe una única técnica que permita detectarlo todo. Sin embargo, a menudo he comprobado que analizar los mecanismos de persistencia es una forma eficaz de abordar el mínimo común denominador de este tipo de malware. Si el atacante desea recopilar datos de un terminal a lo largo del tiempo, su malware debe sobrevivir al reinicio.

Muchos clientes de Tanium utilizan nuestros sensores relacionados con la persistencia, tales como , , «Detalles de programas de ejecución automática», , «», «Rastreo de controladores cargados», , «», «Búsqueda de secuestro del orden de carga de DLL», , «», «Detalles del módulo de servicio» y , «», «Consumidores de eventos WMI»,  , para detectar binarios y scripts sospechosos en toda la empresa.

Una vez que un investigador haya identificado un programa malicioso que genere registros de pulsaciones de teclas o capturas de pantalla, también podría determinar que este utiliza una convención de nomenclatura de archivos de salida coherente. El sensor « » () «Trace File Operations» () « » puede ayudar a identificar operaciones históricas con archivos que coincidan con un nombre o un formato de ruta concretos; los sensores « » () «» «Index Query» () « » pueden, asimismo, localizar archivos en reposo que coincidan con un patrón —o incluso con una secuencia de bytes de cabecera— en cualquier parte del disco.

Otros métodos y reflexiones finales

Esta entrada solo aborda de forma superficial algunas de las formas en que los atacantes pueden sustraer correos electrónicos del ordenador de una víctima o de una red empresarial comprometida. Entre otras técnicas se incluyen:

  • Configuración de Exchange para reenviar de forma encubierta los correos electrónicos de un usuario a una dirección de terceros
  • Los usuarios reenvían intencionadamente su propio correo a una dirección de correo electrónico personal que posteriormente resulta comprometida
  • Marcos de explotación de navegadores, como BEEF[3], que pueden supervisar de forma encubierta la actividad del correo web y otros datos del navegador.
  • Dirigido al software interno utilizado para el archivo interno de correos electrónicos (es decir, como apoyo en litigios y auditorías)
  • Engañar a las víctimas para que utilicen una aplicación móvil maliciosa que se hace pasar por clientes de correo electrónico legítimos
  • … y muchos más …

La protección del correo electrónico empresarial, al igual que la de cualquier otro activo, requiere un análisis minucioso de las amenazas. Tenga en cuenta que, por lo general, los atacantes optarán por la vía que les ofrezca menos resistencia para alcanzar sus objetivos; por lo tanto, no todas las vías de ataque constituyen necesariamente un vector probable o viable que requiera la misma inversión en contramedidas.

En una red plana típica de Windows, las intrusiones localizadas en unos pocos sistemas pueden convertirse rápidamente en una brecha de seguridad más grave que afecte a todo el dominio; por otra parte, infectar a usuarios concretos de interés puede ser «suficiente» para un intruso interesado en un ámbito de datos más limitado. Del mismo modo, el cifrado de mensajes no es una panacea para todos estos vectores de ataque. Sin embargo, puede obligar a un atacante a actuar a través de un conjunto más reducido de sistemas de las víctimas, en lugar de facilitarle el acceso oportunista a los mensajes de cualquier cuenta desde cualquier punto de acceso de la red.

La variedad de técnicas disponibles para robar correo electrónico es abrumadora, y no son solo los objetivos de gran visibilidad los que se enfrentan a esta amenaza. Una visibilidad completa de los dispositivos finales para detectarlos y combatirlos es la mejor forma de garantizar la seguridad de sus correos electrónicos.

[1] https://github.com/officedev/ews-managed-api

[2] http://stackoverflow.com/questions/4454165/how-to-check-an-exchange-mailbox-via-powershell

[3] http://null-byte.wonderhowto.com/how-to/hack-like-pro-hack-web-browsers-with-beef-0159961/

Acerca del autor,: En su cargo de arquitecto jefe de seguridad de Tanium, Ryan Kazanciyan aporta más de 14 años de experiencia en respuesta a incidentes, análisis forense y pruebas de penetración. Ryan supervisa el diseño y la hoja de ruta de las soluciones de respuesta ante amenazas de Tanium, y dirige el equipo de detección y respuesta en terminales (EDR) de Tanium. Antes de incorporarse a Tanium, Ryan supervisó las labores de investigación y corrección en Mandiant, colaborando con decenas de organizaciones de la lista «Fortune 500 » que se habían visto afectadas por ataques selectivos. Ryan ha formado a cientos de especialistas en gestión de incidentes en su calidad de formador para Black Hat y la unidad cibernética del FBI. Es uno de los autores que han colaborado en la obra «Incident Response and Computer Forensics, 3.ª edición» (McGraw-Hill, 2014). Ryan también trabaja como asesor técnico de la serie de televisión «Mr. Robot», donde colabora con los guionistas y el equipo de producción para diseñar los ataques informáticos que se muestran en la serie.