Dark background with blue code overlay
Blog

FritzFrog: La botnet de P2P vuelve a las andadas

Akamai Wave Blue

escrito por

Ben Barnea, Shiran Guez, y Ophir Harpaz

February 10, 2022

Akamai Wave Blue

escrito por

Ben Barnea

Ben Barnea es experto en seguridad en Akamai con interés y experiencia en la realización de investigaciones de seguridad de bajo nivel y de investigaciones de vulnerabilidades en diversas arquitecturas, entre las que se incluyen Windows, Linux, Internet de las cosas y dispositivos móviles. Le gusta descubrir cómo funcionan los mecanismos complejos pero, sobre todo, cómo fallan.

Shiran Guez

escrito por

Shiran Guez

Shiran Guez lleva trabajando en el sector de las redes y las telecomunicaciones desde principios del 2000. Es un entusiasta de la tecnología y trabaja con una mentalidad emprendedora y una actitud de crecimiento. Tiene amplia experiencia en las tecnologías de red de área extensa (WAN) y red de área local (LAN), la integración de redes y aplicaciones, la virtualización, la optimización de WAN o la calidad del servicio (QoS) y la supervisión.

Ophir Harpaz

escrito por

Ophir Harpaz

Ophir dirige el equipo de investigación de seguridad del grupo de seguridad empresarial de Akamai.

Resumen ejecutivo

  • FritzFrog es una campaña de botnets punto a punto descubierta en Guardicore Labs (ahora Akamai Threat Labs) en agosto de 2020

  • La botnet descentralizada ataca cualquier dispositivo que exponga un servidor SSH (instancias de nube, servidores de centro de datos, routers, etc.) y puede ejecutar cualquier carga maliciosa en nodos infectados

  • Su arquitectura punto a punto y su código propietario presentan un alto nivel de sofisticación

  • Recientemente, ha resurgido y ha mostrado un crecimiento en su tasa de infección 10 veces superior en un mes, comprometiendo los servidores de los sectores sanitario, educativo y gubernamental

  • Desde la reaparición de la botnet se han infectado 1500 hosts distintos, la mayoría de los cuales se encuentran en China

  • El malware Golang que se está propagando añade nuevas funciones a la botnet, que incluyen el uso de una red proxy y el ataque a servidores de WordPress

  • La reciente ronda de ataques proporciona más pruebas de los orígenes de FritzFrog, que indican un posible vínculo con un atacante que opera en China, o con uno que se hace pasar por chino

  • Akamai Threat Labs ha actualizado la herramienta de detección FritzFrog para gestionar la versión más reciente del malware

Resumen de FritzFrog Resumen de FritzFrog

FritzFrog v1: resumen rápido

FritzFrog es una botnet punto a punto, lo que significa que su servidor de mando y control no se limita a un solo equipo centralizado, sino que se puede ejecutar desde cada equipo de su red distribuida. Es decir, cada host que ejecuta el proceso de malware pasa a formar parte de la red y puede enviar, recibir y ejecutar los comandos para controlar los equipos de la red.

FritzFrog se propaga a través de SSH. Una vez que encuentra las credenciales de un servidor mediante una técnica de fuerza bruta simple (pero agresiva), establece una sesión SSH con la nueva víctima y coloca el malware ejecutable en el host. A continuación, el malware empieza a escuchar y a esperar a los comandos. Estos comandos incluyen el intercambio de objetivos, el uso compartido de detalles de los equipos afectados y la transferencia de archivos, así como la ejecución de scripts y cargas binarias. La lista completa está disponible en nuestra anterior entrada de blog.

Consideramos que FritzFrog es una botnet de "nueva generación" debido a una combinación de propiedades que la hacen única en el panorama de amenazas:

  • Actualización constante: las bases de datos de los objetivos y los equipos vulnerados se intercambian sin problemas

  • Agresiva: la fuerza bruta se basa en un diccionario amplio; en cambio, DDG, otra botnet P2P recientemente descubierta, solo utilizaba el nombre de usuario "root".

  • Eficiente: los destinos se distribuyen de forma uniforme entre los nodos

  • Propietaria: el protocolo P2P es de propiedad exclusiva y no se basa en ningún protocolo P2P conocido, como μTP

FritzFrog v2: el resurgimiento

Justo después de publicar los detalles sobre FritzFrog en agosto de 2020, el equipo de Guardicore Labs (ahora denominado Akamai Threat Labs) observó una disminución en el número de incidentes de ataque. Sin embargo, a principios de diciembre de 2021, empezamos a ver un repunte de los ataques hacia nuestra red global de sensores.

Un ataque FritzFrog comienza con un ataque de fuerza bruta SSH y continúa con la colocación y ejecución de un archivo. Este archivo comienza inmediatamente a escuchar en el puerto 1234 y a analizar miles de direcciones IP de Internet a través de los puertos 22 y 2222.

Una diferencia entre los ataques antiguos de FritzFrog y los nuevos es el nombre del proceso malicioso. En la primera ronda de ataques, el proceso malicioso se denominó ifconfig o nginx; esta vez, los operadores de FritzFrog eligieron el nombre apache2.

Empezamos a supervisar la nueva variante y vimos un sorprendente aumento en el número de ataques de FritzFrog, alcanzando un máximo de 500 incidentes al día.

 

Número de incidentes de ataque de FritzFrog detectados por nuestros sensores desde su primera aparición Número de incidentes de ataque de FritzFrog detectados por nuestros sensores desde su primera aparición

 

Análisis de las víctimas

Como parte de nuestra investigación sobre la primera campaña de FritzFrog, desarrollamos una herramienta llamada Frogger. Frogger nos permite recopilar información sobre los hosts infectados, como su tiempo de actividad, tasa de hashes, pares y tasa de hashes, si se está ejecutando un malware de criptominería. Este programa toma la dirección IP de un nodo infectado y consulta al host a través de un canal de comunicación cifrado para recibir información sobre su estado. De esta forma, podemos obtener más información sobre el nodo y otros nodos a los que está conectado. Este proceso utiliza la infraestructura de la botnet para hacerlo.

Nuestro análisis de víctimas se basó en dos fuentes: las direcciones IP de los equipos que atacaron nuestros sensores y la información obtenida por Frogger. En concreto, empezamos con la lista de IP de atacantes detectados por nuestros sensores y, posteriormente, ampliamos esa lista consultando a cada uno de ellos sus pares, utilizando Frogger, de forma recursiva.

Los gráficos que se incluyen a continuación muestran el número diario de direcciones IP que atacaron nuestros sensores y la diferencia en el número de atacantes entre días consecutivos. El aumento del número de nodos atacantes (equipos afectados que ejecutan el malware) es preocupante.

 

Número de nodos atacantes al día según lo que han detectado nuestros sensores de amenazas Número de nodos atacantes al día según lo que han detectado nuestros sensores de amenazas
 Gráfico que muestra la diferencia en el número de nodos atacantes entre días consecutivos Gráfico que muestra la diferencia en el número de nodos atacantes entre días consecutivos

 

Durante el periodo de la segunda campaña, FritzFrog logró infectar a más de 1500 hosts distintos. Estos eran equipos servidores pertenecientes a organizaciones de diversos tamaños y sectores, incluidos el sanitario, la educación superior y el gobierno. Detectamos equipos infectados en una red de canales de televisión europea, un fabricante ruso de equipos sanitarios y varias universidades del este asiático. Como muestra el mapa, se detectó una gran concentración de equipos afectados en China.

 

La mayoría de las víctimas se encuentran al norte del ecuador, con una mayor atracción hacia China La mayoría de las víctimas se encuentran al norte del ecuador, con una mayor atracción hacia China

 

Nuevas capacidades de malware

El binario de FritzFrog está escrito en Golang y se puede compilar para que se ejecute en numerosas arquitecturas diferentes. Se empaqueta usando UPX y normalmente se ejecuta bajo uno de los cuatro nombres de proceso siguientes: ifconfig, nginx, apache2 o php-fpm. Ya hemos proporcionado un análisis exhaustivo del malware en nuestra publicación anteriory, por lo que nos centraremos en las nuevas muestras y las aportaciones que realizan.

FritzFrog se actualiza diariamente, a veces varias veces al día. La mayoría de las nuevas versiones incluyen correcciones de errores, pero algunas versiones añaden nuevas capacidades al malware.

Preparación para el ataque a WordPress

FritzFrog lanzó una nueva versión que implementa la infraestructura para el seguimiento de los servidores de WordPress. Contiene funciones responsables de agregar y quitar entradas de las listas tituladas Wordpress y WordpressTargetsTTL. El fragmento de código desensamblado muestra la implementación de un nuevo comando P2P, put wordpress, que agrega una nueva entrada a la lista de objetivos de WordPress. En el momento en el que se redactó este informe, estas listas, que se almacenan en todos los nodos infectados, seguían vacías.

 

El malware no contiene ningún módulo capaz de descifrar o identificar objetivos de WordPress. En base a esto, asumimos que el código es una preparación para nuevas versiones, las cuales podrán comprometer esos objetivos y utilizarlos para fines distintos a la minería, como filtraciones de información, ransomware, etc.

Cadena de proxies Tor

FritzFrog puede actuar como proxy de conexiones SSH salientes utilizando la cadena de proxies Tor mediante la definición del proxy para las conexiones SSH en el puerto local 9050. La cadena de proxies Tor es una red de nodos que proporciona a sus usuarios una mejor privacidad y enmascaramiento mediante la creación de una ruta basada en encapsulación desde el origen hasta el destino; cada nodo solo conoce sus nodos contiguos directos. 

Para el envío de solicitudes al puerto local 9050, FritzFrog utiliza la cadena de proxies Tor para conectarse a dispositivos SSH propios. Un dispositivo propio vería la solicitud entrante como procedente del último nodo de la cadena de proxies. Esto se puede utilizar para ocultar la dirección de los nodos infectados actuales. A día de hoy, aunque la funcionalidad existe, todavía no hemos visto que el malware utilice esta capacidad.

SCP

FritzFrog ahora utiliza SCP para copiarse a sí mismo en un servidor remoto comprometido. Este es diferente de la primera versión, en la que el ejecutable de malware se colocó en una nueva víctima mediante el comando cat en una sesión SSH establecida. La nueva implementación utiliza una biblioteca SCP pública escrita en Golang en GitHub. No pudimos determinar ninguna ventaja significativa de un método sobre el otro. Sin embargo, es llamativo que los escritores de la biblioteca SCP se encuentren en China. 

Lista de bloqueo

La primera versión de FritzFrog implementó una lista de bloqueo para excluir equipos específicos de ser vulnerados por el módulo de descifrado (fuerza bruta). Mientras que un comando P2P especial, putblentry, permite la inserción dinámica de entradas a esta lista, las nuevas versiones codifican varias entradas por adelantado.

Algunas de estas entradas especifican un nombre Unix, y otras una dirección IP, pero nunca ambas.

Entradas de lista de bloqueo codificadas en las nuevas muestras de FritzFrog

[
{"Address": "",
 "Uname_match": "[redacted]dddz.me 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017"},
{"Address": "",
"Uname_match": "[redacted]-1 4.4.0-151-generic #178-Ubuntu SMP Tue Jun 11 08: 30: 22 UTC 2019"},
{"Address": "",
"Uname_match": "[redacted].amzn2.x86_64 #1 SMP Mon Jun 18 22: 33: 07 UTC 2018 x86_64 GNU/Linux"},
{"Address": "",
"Uname_match": "[redacted]-generic #113-Ubuntu SMP Thu Jul 9 23: 41: 39 UTC 2020"},
{"Address": "",
"Uname_match": "[redacted] raspberrypi 4.4.32-v7+ #924 SMP Tue Nov 15 18: 11: 28 GMT 2016 armv7l GNU/Linux"},
{"Address": "",
"Uname_match": [redacted] 3.10.0-123.4.4.el7.x86_64 #1 SMP Fri Jul 25 05: 07: 12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux"},
{"Address": "",
"Uname_match": [redacted] 4.18.0-193.28.1.el8_2.x86_64 #1 SMP Thu Oct 22 00: 20: 22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux"},
{"Address": "[redacted].24: 22",
"Uname_match": ""},
{"Address": "[redacted].88: 22",
"Uname_match": ""},
{"Address": "[redacted].26: 22",
"Uname_match": ""}]

 

Las entradas sugieren que los operadores procuran no infectar sistemas de gama baja con bajos recursos, como dispositivos Raspberry Pi o imágenes EC2 de bajos recursos en AWS.

Una IP de la lista de bloqueo es de Rusia. Tiene varios puertos abiertos y una larga lista de vulnerabilidades no corregidas, por lo que puede ser un señuelo. Además, una segunda entrada apunta a un sinkhole de botnet de código abierto. Estas dos entradas sugieren que los operadores están intentando evadir la detección y el análisis.

Dos de las direcciones IP tienen ubicaciones geográficas en Estados Unidos. Una entrada bloquea la Universidad de Maryland, por motivos que no están claros, y la segunda muestra una broma práctica, o una advertencia cuando se examina, aparentemente consciente de la posible investigación del malware.

La advertencia que aparece muestra "curiosity killed the cat" La advertencia que aparece muestra "curiosity killed the cat"

 

Orígenes y atribución

Los cambios y las adiciones recientes de esta campaña nos han permitido examinar los posibles orígenes de este malware. Aunque no podemos estar seguros de su verdadero origen, creemos que compartir esta información puede ser valioso. 

La primera prueba procede de una de las bibliotecas recién agregadas compiladas en el malware FritzFrog denominada scp, que implementa el protocolo de copia segura para las transferencias de archivos a través de SSH. La biblioteca está escrita en Go y su código lo comparte en un repositorio de GitHub un usuario ubicado en Shanghái. Existe una bifurcación en este repositorio que realizó un segundo individuo en Shanghái.

Otra prueba que vincula a China procede de la actividad de criptominería de FritzFrog. Nuestro equipo de investigación ha logrado encontrar nuevas direcciones de cartera, así como nuevos pools de minería que se utilizan en el proceso de criptominería. Una de las nuevas direcciones de cartera observadas (que se indica a continuación) también se utilizó como parte de la campaña de botnets Mozi , cuyos autores fueron arrestados recientemente en China.

Dirección de la cartera Monero de FritzFrog conectada a Mozi

47BD6QNfkWf8ZMQSdqp2tY1AdG8ofsEPf4mcDp1YB4AX32hUjoLjuDaNrYzXk7cQcoPBzAuQrmQTgNgpo6XPqSBLCnfsjaV

Estas pruebas, aunque no son abrumadoras, nos hacen creer que existe un posible vínculo con un atacante que opera en China, o con un atacante que se hace pasar por chino. Por último, la supervisión de los datos de los ataques ha manifestado un alto nivel de actividad en China y durante toda la campaña. Hasta ahora, aproximadamente el 37 % de los nodos infectados parecen estar ubicados en China. 

Prevención y mitigación

 

Herramienta de detección de FritzFrog

Akamai proporciona un script de detección de FritzFrog para ejecutarlo en servidores SSH. Busca los siguientes indicadores de FritzFrog:

  • La ejecución de procesos denominados nginx, ifconfig, php-fpm, apache2 o libexeccuyo archivo ejecutable ya no existe en el sistema de archivos (como se muestra a continuación)

  • Escucha en el puerto 1234

Además, el tráfico TCP a través del puerto 5555 puede indicar un tráfico de red al grupo Monero.

Recomendaciones

  • Mantenga los sistemas siempre actualizados y con los parches al día

  • Implemente un inicio de sesión sin contraseña mediante un sistema sólido de gestión y rotación de claves

  • Habilite una auditoría de inicio de sesión del sistema con alertas

  • Supervise el archivo authorized_hosts en Linux

  • Configure la lista de permitidos explícitos del inicio de sesión SSH

  • Desactive el acceso SSH a la raíz

  • Habilite la protección de DNS basada en la nube de Akamai con la definición de las amenazas y las aplicaciones empresariales no relacionadas, como la minería de criptomonedas, para que se bloqueen  



Akamai Wave Blue

escrito por

Ben Barnea, Shiran Guez, y Ophir Harpaz

February 10, 2022

Akamai Wave Blue

escrito por

Ben Barnea

Ben Barnea es experto en seguridad en Akamai con interés y experiencia en la realización de investigaciones de seguridad de bajo nivel y de investigaciones de vulnerabilidades en diversas arquitecturas, entre las que se incluyen Windows, Linux, Internet de las cosas y dispositivos móviles. Le gusta descubrir cómo funcionan los mecanismos complejos pero, sobre todo, cómo fallan.

Shiran Guez

escrito por

Shiran Guez

Shiran Guez lleva trabajando en el sector de las redes y las telecomunicaciones desde principios del 2000. Es un entusiasta de la tecnología y trabaja con una mentalidad emprendedora y una actitud de crecimiento. Tiene amplia experiencia en las tecnologías de red de área extensa (WAN) y red de área local (LAN), la integración de redes y aplicaciones, la virtualización, la optimización de WAN o la calidad del servicio (QoS) y la supervisión.

Ophir Harpaz

escrito por

Ophir Harpaz

Ophir dirige el equipo de investigación de seguridad del grupo de seguridad empresarial de Akamai.