FritzFrog: la red de bots P2P ataca de nuevo

 

Por Enric Mañez, enterprise sales executive senior de Akamai  

Akamai

 

  • FritzFrog es una campaña de botnet peer-to-peer descubierta por Guardicore Labs (ahora Akamai Threat Labs) en agosto de 2020
  • La red de bots descentralizada se dirige a cualquier dispositivo que exponga un servidor SSH - instancias en la nube, servidores de centros de datos, routers, etc. - y es capaz de ejecutar cualquier carga maliciosa en los nodos infectados
  • Su arquitectura peer-to-peer y su código propietario demuestran un alto nivel de sofisticación
  • Recientemente ha resurgido y ha multiplicado por 10 su tasa de infección en un mes, comprometiendo servidores de los sectores sanitario, educativo y gubernamental
  • Se han infectado 1.500 hosts distintos desde la reaparición de la red de bots, la mayoría de ellos en China
  • El malware Golang que se está propagando añade nuevas funcionalidades a la red de bots, incluyendo el uso de una red proxy y el ataque a servidores de WordPress
  • La reciente ronda de ataques proporciona más pruebas sobre los orígenes de FritzFrog, indicando un posible vínculo con un actor que opera en China, o que se hace pasar por chino
  • Akamai Threat Labs ha actualizado la herramienta de detección de FritzFrog para hacer frente a la última versión del malware

 

 

24.000 ataques a nuestra red mundial de sensores

1.500 víctimas hasta la fecha

35 días de vida máxima

<10 días de vida media

 

FritzFrog v1 - un resumen rápido

 

FritzFrog es una red de bots peer-to-peer, lo que significa que su servidor de comando y control no se limita a una sola máquina centralizada, sino que puede hacerse desde cada máquina de su red distribuida. En otras palabras, cada host que ejecuta el proceso de malware se convierte en parte de la red, y es capaz de enviar, recibir y ejecutar los comandos para controlar las máquinas en la red.

 

FritzFrog se propaga a través de SSH. Una vez que encuentra las credenciales de un servidor mediante una sencilla (aunque agresiva) técnica de fuerza bruta, establece una sesión SSH con la nueva víctima y deja caer el ejecutable del malware en el host. A continuación, el malware comienza a escuchar y a esperar comandos. Estos comandos incluyen el intercambio de objetivos, compartir los detalles de las máquinas comprometidas y transferir archivos, así como ejecutar scripts y cargas útiles binarias. La lista completa de comandos está disponible en nuestra entrada anterior del 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 las amenazas:

 

  • Actualización constante - Las bases de datos de los objetivos y las máquinas vulneradas se intercambian sin problemas
  • Agresivo: la fuerza bruta se basa en un extenso diccionario; en comparación, DDG, otra red de bots P2P descubierta recientemente, sólo utilizaba el nombre de usuario "root".
  • Eficiente - Los objetivos se distribuyen uniformemente entre los nodos
  • Propietario - El protocolo P2P es completamente propietario, y no se basa en protocolos P2P conocidos 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 Akamai Threat Labs) notó un descenso 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 una fuerza bruta SSH, y continúa con la caída y ejecución de un archivo. Este archivo comienza inmediatamente a escuchar en el puerto 1234 y a escanear miles de direcciones IP de Internet a través de los puertos 22 y 2222.

 

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

 

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

 

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, incluyendo su tiempo de actividad, hashrate, peers y hasrate, si se está ejecutando un cryptominer. Este programa toma la dirección IP de un nodo infectado y lo consulta a través de un canal de comunicación cifrado para recibir información sobre su estado. De este modo, podemos saber más sobre el nodo y otros nodos a los que está conectado. Este proceso aprovecha la infraestructura de la botnet para hacerlo.

 

Nuestro análisis de las víctimas se basó en dos fuentes: las direcciones IP de las máquinas que atacaron nuestros sensores y la información obtenida por Frogger. Es decir, comenzamos con la lista de IPs de atacantes vistas por nuestros sensores, y luego ampliamos esa lista consultando a cada una de ellas por sus pares, usando Frogger, recursivamente.

 

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 -máquinas víctimas que ejecutan el malware- es preocupante.

 

Durante el tiempo que duró la segunda campaña, FritzFrog consiguió infectar más de 1.500 hosts distintos. Se trataba de máquinas servidoras pertenecientes a organizaciones de diversos tamaños y sectores, como la sanidad, la enseñanza superior y la administración pública. Encontramos máquinas infectadas en una red de canales de televisión europeos, en un fabricante ruso de equipos sanitarios y en varias universidades de Asia oriental. 

 

Nuevas capacidades de malware

 

El binario de FritzFrog está escrito en Golang y puede ser compilado para ejecutarse en muchas arquitecturas diferentes. Se empaqueta utilizando UPX y suele ejecutarse bajo uno de los cuatro nombres de proceso: ifconfig, nginx, apache2 o php-fpm. En nuestra anterior publicación hemos realizado un análisis exhaustivo del malware, por lo que nos centraremos en las nuevas muestras y en las novedades que aportan.

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

 

Preparación para el ataque a WordPress

 

FritzFrog ha lanzado una nueva versión que implementa la infraestructura para rastrear los servidores de WordPress. Contiene funciones responsables de añadir y eliminar entradas de las listas tituladas Wordpress y WordpressTargetsTTL. El fragmento de código desensamblado que aparece a continuación muestra la implementación de un nuevo comando P2P, put wordpress, que añade una nueva entrada a la lista de objetivos de WordPress. En el momento de redactar este informe, estas listas -que se guardan en todos los nodos infectados- siguen estando vacías.

 

El malware no contiene ningún módulo capaz de crackear o identificar objetivos de WordPress. Basándonos en esto, suponemos que el código es una preparación para nuevas versiones, que serán capaces de comprometer esos objetivos y utilizarlos con fines distintos a la minería, como fugas de información, ransomware, etc.

Cadena de proxies Tor

FritzFrog puede proxy conexiones SSH salientes utilizando la cadena de proxy Tor estableciendo el proxy para conexiones SSH al puerto local 9050. La cadena de proxy Tor es una red de nodos que proporciona a sus usuarios una mejor privacidad y enmascaramiento creando una ruta basada en la encapsulación desde el origen hasta el destino; cada nodo sólo es consciente de sus nodos vecinos directos.

Proxyando las peticiones al puerto local 9050, FritzFrog utiliza la cadena proxy Tor para conectarse a los dispositivos SSH propios. Un dispositivo propio vería la petición entrante como procedente del último nodo en la cadena proxy. Esto puede ser utilizado 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 esta capacidad sea utilizada por el malware.

SCP

 

FritzFrog utiliza ahora SCP para copiarse a sí mismo en un servidor remoto comprometido. Esto es diferente de la primera versión, en la que el ejecutable del malware se dejaba caer en una nueva víctima utilizando el comando cat a través de 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 notable que los escritores de la biblioteca SCP se encuentran en China

Lista de bloqueo

La primera versión de FritzFrog implementó una lista de bloqueo, para excluir máquinas específicas de ser violadas por el módulo de cracker (fuerza bruta). Mientras que un comando P2P especial, putblentry, permite la inserción dinámica de entradas en 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 la 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 buscan evitar infectar sistemas de gama baja con pocos recursos, como dispositivos Raspberry Pi o imágenes EC2 de bajos recursos en AWS.

 

Una de las IP de la lista de bloqueo es de Rusia. Tiene múltiples puertos abiertos y una larga lista de vulnerabilidades sin parchear, por lo que puede ser un honeypot. Además, una segunda entrada apunta a un sumidero 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 están ubicadas en Estados Unidos. Una de las entradas bloquea la Universidad de Maryland, por razones que no están claras, y la segunda muestra una broma pesada o una advertencia cuando se navega a ella, aparentemente consciente de la posible investigación del malware.

 

Origen y atribución

Los recientes cambios y adiciones a 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 proviene de una de las bibliotecas recién añadidas y compiladas en el malware FritzFrog, llamada scp, que implementa el protocolo de copia segura para la transferencia de archivos a través de SSH. La librería está escrita en Go y su código se comparte en GitHub, en un repositorio de un usuario ubicado en Shanghai. En este repositorio existe un fork, que fue realizado por un segundo individuo en Shanghai.

Otra prueba que vincula a China proviene de la actividad de criptominería de FritzFrog. Nuestro equipo de investigación ha conseguido encontrar nuevas direcciones de monederos, así como nuevos pools de minería utilizados en el proceso de criptominería. Una de las nuevas direcciones de monedero observadas (indicada a continuación) también se utilizó como parte de la campaña de la red de bots Mozi, cuyos autores fueron detenidos recientemente en China.

 

 

Dirección del monedero FritzFrog Monero conectado a Mozi

47BD6QNfkWf8ZMQSdqp2tY1AdG8ofsEPf4mcDp1YB4AX32hUjoLjuDaNrYzXk7cQcoPBzAuQrmQTgNgpo6XPqSBLCnfsjaV

 

Por último, el seguimiento de los datos de los ataques ha demostrado un alto nivel de actividad en China y sus alrededores a lo largo de la campaña. Hasta ahora, aproximadamente el 37% de los nodos infectados parecen estar ubicados en China.

 

Estos puntos de evidencia, aunque no son condenatorios, nos llevan a creer que existe un posible vínculo con un actor que opera en China, o un actor que se hace pasar por chino.

 

Prevención y mitigación

 

Herramienta de detección FritzFrog

 

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

  • Procesos en ejecución llamados nginx, ifconfig, php-fpm, apache2 o libexec, cuyo archivo ejecutable ya no existe en el sistema de archivos (como se ve a continuación)
  • Puerto de escucha 1234

 

  • Running processes named nginx, ifconfig, php-fpm, apache2, or libexec, whose executable file no longer exists on the file system (as seen below)
  • Listening port 1234

 

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

Recomendaciones:

  • Mantenga siempre los sistemas actualizados y parcheados
  • Implantar el inicio de sesión sin contraseña utilizando un sistema de gestión y rotación de claves fuerte
  • Habilitar la auditoría de inicio de sesión del sistema con alertas
  • Supervisar el archivo authorized_hosts en Linux
  • Configurar una lista de permisos explícitos para el inicio de sesión SSH
  • Desactivar el acceso root de SSH
  • Habilitar la protección DNS basada en la nube de Akamai con amenazas y aplicaciones empresariales no relacionadas, como la minería de monedas, configuradas para bloquearlas