SophosLabs Uncut

Casi la mitad del malware ahora usa TLS para ocultar las comunicaciones

Transport Layer Security ha sido uno de los mayores contribuyentes a la privacidad y seguridad de las comunicaciones por Internet durante la última década. El protocolo criptográfico TLS se utiliza para proteger una parte cada vez mayor del tráfico de datos de aplicaciones, mensajería y web de Internet. El protocolo web seguro HTTP (HTTPS), el protocolo de correo electrónico StartTLS, la red anónima Tor y las redes privadas virtuales, como las basadas en el protocolo OpenVPN, aprovechan TLS para cifrar y encapsular sus contenidos, protegiéndolos de ser observados o modificados en tránsito.

Durante la última década, y particularmente a raíz de las revelaciones sobre la vigilancia masiva de Internet, el uso de TLS ha crecido para cubrir la mayoría de las comunicaciones de Internet. Según los datos del navegador de Google, el uso de HTTPS ha crecido de poco más del 40 por ciento de todas las visitas a páginas web en 2014 al 98 por ciento en marzo de 2021.

No debería sorprender, entonces, que los operadores de malware también hayan adoptado TLS esencialmente por las mismas razones: para evitar que los defensores detecten y detengan la implementación de malware y el robo de datos. Hemos visto un crecimiento espectacular durante el año pasado en el malware que usa TLS para ocultar sus comunicaciones. En 2020, el 23 por ciento del malware que detectamos que se comunicaba con un sistema remoto a través de Internet utilizaba TLS; hoy, es casi el 46 por ciento.

 

Un desglose de las comunicaciones salientes de malware durante los primeros 3 meses de 2021.

También hay una fracción significativa de las comunicaciones TLS que utilizan un puerto de Protocolo de Internet distinto del 443, como el malware que utiliza un proxy Tor o SOCKS sobre un número de puerto no estándar. Consultamos los registros de transparencia de certificados con los nombres de host asociados con las comunicaciones de Internet de malware en puertos distintos del 443, 80 y 8080, y descubrimos que el 49 por ciento de los hosts tenían certificados TLS asociados que fueron emitidos por una autoridad de certificación (CA). . Una pequeña fracción de los demás comprobados manualmente utilizaba certificados autofirmados.

Pero una gran parte del crecimiento en el uso general de TLS por parte del malware se puede vincular en parte al mayor uso de servicios web y en la nube legítimos protegidos por TLS, como Discord, Pastebin, Github y los servicios en la nube de Google, como repositorios de componentes de malware. como destinos de datos robados e incluso para enviar comandos a redes de bots y otro malware. También está relacionado con el mayor uso de Tor y otros proxies de red basados ​​en TLS para encapsular las comunicaciones maliciosas entre el malware y los actores que las implementan.

 

Un desglose de los destinos del tráfico “callhome” del malware TLS por ISP durante los primeros tres meses de 2021.

Los servicios en la nube de Google fueron el destino del nueve por ciento de las solicitudes de TLS de malware, seguido de cerca por BSNL de India. Durante el mes de marzo de 2021, vimos un aumento en el uso de malware alojado en Cloudflare, en gran parte debido a un aumento en el uso de la red de entrega de contenido de Discord, que se basa en Cloudflare, que por sí sola representó el 4 por ciento de los detectados. Malware TLS ese mes. Informamos sobre 9,700 enlaces relacionados con malware a Discord; muchos eran específicos de Discord, apuntando al robo de credenciales de usuario, mientras que otros eran paquetes de entrega para otros ladrones de información y troyanos.

En conjunto, casi la mitad de todas las comunicaciones TLS de malware se dirigieron a servidores en Estados Unidos e India.


Hemos visto un aumento en el uso de TLS en ataques de ransomware durante el año pasado, especialmente en ransomware implementado manualmente, en parte debido al uso de los atacantes de herramientas ofensivas modulares que aprovechan HTTPS. Pero la gran mayoría de lo que detectamos día a día en el tráfico TLS malicioso proviene del malware de compromiso inicial: cargadores, goteros e instaladores basados ​​en documentos que regresan a páginas web seguras para recuperar sus paquetes de instalación.

Para obtener información sobre cómo ha cambiado el uso de TLS en el malware, profundizamos en nuestra telemetría de detección para medir cuánto TLS usa el malware, identificar el malware más común que aprovecha TLS y cómo ese malware hace uso de TLS. -Comunicaciones cifradas. Según nuestra telemetría de detección, descubrimos que, si bien TLS todavía representa un promedio de poco más del dos por ciento del tráfico general que Sophos clasifica como “hogar de llamada de malware” durante un período de tres meses, el 56 por ciento de los servidores C2 únicos (identificados por DNS nombres de host) que se comunicaron con malware usaban HTTPS y TLS. Y de eso, casi una cuarta parte es con infraestructura que reside en el entorno de nube de Google.

Paquetes sorpresa

Las comunicaciones de malware generalmente se dividen en tres categorías: descarga de malware adicional, exfiltración de datos robados y recuperación o envío de instrucciones para activar funciones específicas (comando y control). Todos estos tipos de comunicaciones pueden aprovechar el cifrado TLS para evadir la detección por parte de los defensores. Pero la mayoría del tráfico de TLS que encontramos vinculado al malware era del primer tipo: droppers, loaders y otro malware que descargaba malware adicional al sistema que infectaban, usando TLS para evadir la inspección básica de la carga útil.

No se necesita mucha sofisticación para aprovechar TLS en un cuentagotas de malware, porque la infraestructura habilitada para TLS para entregar malware o fragmentos de código está disponible gratuitamente. Con frecuencia, los usuarios y los cargadores utilizan sitios web legítimos y servicios en la nube con soporte TLS incorporado para disfrazar aún más el tráfico. Por ejemplo, este tráfico de un cuentagotas Bladabindi RAT muestra que intenta recuperar su carga útil de una página de Pastebin. (La página ya no existe).

Wireshark screen capture of dropper calling Pastebin page
Tráfico TLS de un cuentagotas Bladabini RAT que intenta recuperar el código de segunda etapa de Pastebin a través de TLS.

Hemos visto numerosos casos de software malicioso que se comportan de esta manera en nuestra investigación. Se observó que el cuentagotas basado en PowerShell para LockBit ransomware recuperaba un script adicional de una hoja de cálculo de Google Docs a través de TLS, así como de otro sitio web. Y también se ha observado un cuentagotas para AgentTesla (que se analiza más adelante en este informe) accediendo a Pastebin a través de TLS para recuperar fragmentos de código. Si bien Google y Pastebin a menudo cierran rápidamente los documentos y sitios que alojan malware en su plataforma, muchas de estas fuentes C2 se abandonan después de una sola campaña de spam, y los atacantes simplemente crean otras nuevas para su próximo ataque.

A veces, el malware utiliza varios servicios de esta manera en un solo ataque. Por ejemplo, uno de los numerosos lanzadores de malware que encontramos en la red de entrega de contenido de Discord cayó en otra etapa también alojada en Discord, que a su vez intentó cargar un ejecutable directamente desde GitHub. (El código de GitHub ya se había eliminado por ser malicioso; revelamos las etapas iniciales del ataque de malware a Discord, junto con muchos otros programas maliciosos, quienes los eliminaron).

Una captura de paquetes de malware que recupera descargas de Discord y GitHub

El tráfico de descarga de malware en realidad constituye la mayor parte del tráfico C2 basado en TLS que observamos. En febrero de 2021, por ejemplo, los droppers constituían más del 90 por ciento del tráfico de TLS C2, una cifra que se acerca mucho a los datos de telemetría de detección de C2 estáticos asociados con un malware similar mes a mes desde enero hasta marzo de 2021.

Canales encubiertos

Los operadores de software malintencionado pueden utilizar TLS para ofuscar el tráfico de mando y control. Al enviar solicitudes HTTPS o conectarse a través de un servicio proxy basado en TLS, el malware puede crear un shell inverso, lo que permite que los comandos se pasen al malware o que el malware recupere bloques de secuencias de comandos o claves necesarias para funciones específicas. Los servidores de comando y control pueden ser un servidor web remoto dedicado o pueden basarse en uno o más documentos en servicios legítimos en la nube. Por ejemplo, el troyano bancario portugués Lampion utilizó un documento de texto de Google Docs como fuente de una clave necesaria para desbloquear parte de su código, y eliminar el documento actuó como un interruptor de emergencia. Al aprovechar Google Docs, los actores detrás de Lampion pudieron ocultar las comunicaciones de control con el malware y evadir la detección basada en la reputación mediante el uso de un host confiable.

Google Docs screenshot

El documento de Google (ahora destruido) solía pasar una clave al troyano bancario Lampion.El malware puede utilizar el mismo tipo de conexión para extraer información confidencial, transmitiendo credenciales de usuario, contraseñas, cookies y otros datos recopilados al operador del malware. Para ocultar el robo de datos, el malware puede encapsularlo en un HTTPS POST basado en TLS o exportarlo a través de una conexión TLS a una API de servicio en la nube, como las API de “bot” de Telegram o Discord.

SystemBC

Un ejemplo de cómo los atacantes utilizan TLS de forma malintencionada es SystemBC, una herramienta de comunicaciones malintencionada multifacética utilizada en varios ataques de ransomware recientes. Las primeras muestras de SystemBC, detectadas hace más de un año, actuaron principalmente como un proxy de red, creando lo que equivalía a una conexión de red privada virtual para atacantes basada en la conexión proxy remota SOCKS5 cifrada con TLS, proporcionando comunicaciones ocultas para otro malware. Pero el malware ha seguido evolucionando, y las muestras más recientes de SystemBC son troyanos de acceso remoto (RAT) más completos que brindan una puerta trasera persistente para los atacantes una vez implementados. La versión más reciente de SystemBC puede emitir comandos de Windows, así como entregar y ejecutar scripts, ejecutables maliciosos y bibliotecas de vínculos dinámicos (DLL), además de su función como proxy de red.

Sin embargo, SystemBC no es del todo sigiloso. Hay una gran cantidad de tráfico que no es de TLS ni de Tor generado por SystemBC, sintomático de la adición incremental de funciones que se ven en muchos programas maliciosos de larga duración. La muestra que analizamos recientemente tiene un “latido” de TCP que se conecta a través del puerto 49630 a un host codificado en el propio SystemBC RAT.

La primera conexión TLS es una solicitud HTTPS a un proxy para IPify, una API que se puede utilizar para obtener la dirección IP pública del sistema infectado. Pero esta solicitud no se envía en el puerto 443, el puerto HTTPS estándar, sino que se envía en el puerto 49271. Este uso de puerto no estándar es el comienzo de un patrón.

WIRESHARK SCREENSHOT
SystemBC usando TLS y HTTPS para conectarse a IPify y obtener la dirección pública de Internet del sistema.

SystemBC luego intenta obtener datos sobre el consenso actual de la red Tor, conectándose a direcciones IP codificadas con una solicitud HTTP GET, pero a través de los puertos 49272 y 49273. SystemBC usa las conexiones para descargar información sobre la configuración actual de la red Tor.

SystemBC recopila datos de la red Tor.

A continuación, SystemBC establece una conexión TLS a una puerta de enlace Tor elegida de los datos de la red Tor. Nuevamente, usa otro puerto no estándar: 49274. Y construye el circuito Tor hasta el destino de su túnel Tor usando datos de directorio recopilados a través del puerto 49275 a través de otra solicitud HTTP. Allí termina la progresión de los puertos secuenciales y, en la muestra que analizamos, intenta buscar otro ejecutable de malware a través de una solicitud HTTP abierta a través del puerto estándar.


Flow chart of SystemBC network behavior

El archivo recuperado por esta muestra, henos.exe, es otra puerta trasera que se conecta a través de TLS en el puerto estándar (443) a un sitio web que devuelve enlaces a canales de Telegram, una señal de que el actor detrás de esta instancia de SystemBC está evolucionando tácticas. Es probable que SystemBC continúe evolucionando también, ya que sus desarrolladores abordan el uso mixto de HTTP y TLS y los puertos no estándar, algo predecibles, que permiten que SystemBC se tome las huellas digitales fácilmente.

AgenteTesla

Al igual que SystemBC, AgentTesla, un ladrón de información que también puede funcionar en algunos casos como RAT, ha evolucionado a lo largo de su larga historia. Activo durante más de siete años, AgentTesla se ha actualizado recientemente con una opción para usar la red de anonimato Tor para ocultar el tráfico con TLS.

También hemos visto el uso de TLS en uno de los descargadores más recientes de AgentTesla, ya que los desarrolladores han utilizado servicios web legítimos para almacenar fragmentos de malware codificados en formato base64 en Pastebin y un servicio similar llamado Hastebin. El descargador de la primera etapa intenta evadir la detección al parchear la Interfaz de software anti-malware de Windows (AMSI) para evitar el escaneo en memoria de los fragmentos de código descargados a medida que se unen y decodifican.

Wireshark screenshot-agenttesla installer
A packet capture of traffic from AgentTesla’s installer attempting to connect to Pastebin over TLS.

 

La adición de Tor a AgentTesla en sí se puede utilizar para ocultar comunicaciones a través de HTTP. También hay otros protocolos C2 opcionales en AgentTesla que podrían estar protegidos por TLS: la API de Telegram Bot, que usa un servidor HTTPS para recibir mensajes. Sin embargo, el desarrollador de AgentTesla no implementó comunicaciones HTTPS en el malware (al menos por ahora); no puede ejecutar un protocolo de enlace TLS. Telegram acepta mensajes HTTP sin cifrar enviados a su bot API.

Dridex

Dridex es otra familia de malware de larga duración que ha experimentado una evolución reciente sustancial. Dridex, principalmente un troyano bancario, se detectó por primera vez en 2011, pero ha evolucionado sustancialmente. Puede cargar nuevas funciones a través de módulos descargados, de forma similar al troyano Trickbot. Los módulos Dridex pueden descargarse juntos en un compromiso inicial del sistema afectado, o recuperarse más tarde por el módulo cargador principal. Cada módulo es responsable de realizar funciones específicas: robar credenciales, extraer datos de cookies del navegador o certificados de seguridad, registrar pulsaciones de teclas o tomar capturas de pantalla.

El cargador de Dridex se ha actualizado para ocultar las comunicaciones, encapsulándolas con TLS. Utiliza HTTPS en el puerto 443 tanto para descargar módulos adicionales como para extraer los datos recopilados al servidor C2. Los datos extraídos también se pueden cifrar con RC4 para ocultarlos y protegerlos aún más. Dridex también tiene una infraestructura resistente de servidores de comando y control (C2), lo que permite que el malware instalado se transforme en una copia de seguridad si su servidor C2 original deja de funcionar.

Estas actualizaciones han convertido a Dridex en una amenaza continua, y los cargadores de Dridex se encuentran entre las familias de malware más comunes detectadas mediante TLS, eclipsadas solo por el siguiente grupo de amenazas en nuestra galería de pícaros de TLS: herramientas de “seguridad ofensiva” listas para usar reutilizadas por los ciberdelincuentes.

Metasploit y Cobalt Strike

Tanto los agentes malintencionados como los profesionales de la seguridad han utilizado durante mucho tiempo herramientas de seguridad ofensivas. Estas herramientas comerciales y de código abierto, incluidos los kits de herramientas modulares Cobalt Strike y Metasploit, se crearon para pruebas de penetración y evaluaciones de seguridad del “equipo rojo”, pero los grupos de ransomware las han adoptado por su flexibilidad.

Durante el último año, hemos visto un aumento en el uso de herramientas derivadas de plataformas de seguridad ofensivas en ataques de ransomware implementados manualmente, utilizados por atacantes para ejecutar scripts, recopilar información sobre otros sistemas en la red, extraer credenciales adicionales y difundir ransomware y otro malware.

A Cobalt Strike configuration file from a recent Conti ransUn archivo de configuración de Cobalt Strike de un reciente ataque de ransomware Conti. La baliza Cobalt Strike utilizó HTTPS y TLS para comunicarse con el servidor C2 en el ataque.omware attack. The Cobalt Strike beacon used HTTPS and TLS to communicate with the C2 server in the attack.

En conjunto, las balizas Cobalt Strike y los derivados de Metasploit “Meterpreter” constituían más del 1 por ciento de todo el malware detectado mediante TLS, un número significativo en comparación con otras familias de malware importantes.

Y todo el resto

Las aplicaciones potencialmente no deseadas (PUA), particularmente en la plataforma macOS, también aprovechan TLS, a menudo a través de extensiones de navegador que se conectan subrepticiamente a los servidores C2 para exfiltrar información e inyectar contenido en otras páginas web. Hemos visto que Bundlore usa TLS para ocultar scripts maliciosos e inyectar anuncios y otro contenido en páginas web, sin ser detectado. En general, encontramos que más del 89 por ciento de las amenazas de macOS con comunicaciones C2 usaban TLS para llamar a casa o recuperar código dañino adicional.

Hay muchas otras amenazas a la privacidad y la seguridad que acechan en el tráfico TLS más allá del malware y las aplicaciones no deseadas. Las campañas de phishing se basan cada vez más en sitios web con certificados TLS, ya sea registrados con un nombre de dominio engañoso o proporcionados por un proveedor de servicios en la nube. Los ataques de phishing de Google Forms pueden parecer fáciles de detectar, pero los usuarios capacitados para “buscar el candado” junto con las direcciones web en su navegador pueden escribir casualmente sus datos y credenciales de identificación personal.

Even with the Comic Sans font and the Google Forms URL, some may still fall for this phish.

 

Análisis de tráfico

Todo esto se suma a un aumento de más del 100 por ciento en las comunicaciones de malware basadas en TLS desde 2020. Y esa es una estimación conservadora, ya que se basa únicamente en lo que pudimos identificar a través del análisis de telemetría y los datos del host.

Como hemos señalado, algunos usan TLS en puertos IP no estándar, lo que hace imposible una evaluación completamente precisa del uso de TLS sin un análisis más profundo de paquetes de sus comunicaciones. Por lo tanto, las estadísticas incluidas en este informe no reflejan la gama completa de comunicaciones maliciosas basadas en TLS, y las organizaciones no deben depender únicamente de los números de puerto relacionados con las comunicaciones para identificar el tráfico malicioso potencial. TLS se puede implementar en cualquier puerto IP asignable y, después del protocolo de enlace inicial, se ve como cualquier otro tráfico de aplicación TCP.

Aun así, la tendencia más preocupante que hemos observado es el uso de servicios web y en la nube comerciales como parte de la implementación, el comando y el control de malware. El abuso de las plataformas de comunicación legítimas por parte de los autores de malware les brinda el beneficio de las comunicaciones encriptadas proporcionadas por Google Docs, Discord, Telegram, Pastebin y otros, y, en algunos casos, también se benefician de la reputación “segura” de esas plataformas.

También vemos el uso de herramientas de seguridad ofensivas listas para usar y otras herramientas listas para usar e interfaces de programación de aplicaciones que hacen que el uso de comunicaciones basadas en TLS sea más accesible y continúe creciendo. Los mismos servicios y tecnologías que han facilitado enormemente la obtención de certificados TLS y la configuración de sitios web HTTPS para pequeñas organizaciones e individuos también han facilitado que los actores malintencionados se mezclen con el tráfico legítimo de Internet y han reducido drásticamente el trabajo necesario para cambiar o replicar con frecuencia. Infraestructura C2.

Todos estos factores hacen que la defensa contra los ataques de malware sea mucho más difícil. Sin una defensa en profundidad, es cada vez menos probable que las organizaciones detecten amenazas en el cable antes de que los atacantes las implementen.

SophosLabs desea agradecer a Suriya Natarajan, Anand Aijan, Michael Wood, Sivagnanam Gn, Markel Picado y Andrew Brandt por sus contribuciones a este informe.

Dejar un comentario

Your email address will not be published.