Descargo de responsabilidad: el análisis del contenido del servidor y las muestras se realizó el jueves 20 de septiembre. Sigue el Blog de Avast para más actualizaciones. 

Introducción

2018 ha sido  un año en el que las variantes Mirai y QBot no han dejado de aparecer. Ahora cualquier script para niños puede usar el código fuente de Mirai, hacer algunos cambios, darle un nuevo nombre que suene a japonés y luego lanzarlo como una nueva botnet.

Durante la semana pasada, hemos estado observando una nueva variedad de malware, que llamamos Torii, que se diferencia de Mirai y otras botnets que conocemos, particularmente en las técnicas avanzadas que utiliza.

A diferencia de las botnets del IoT mencionadas anteriormente, esta intenta ser más sigilosa y persistente una vez que el dispositivo está comprometido, y no (todavía) hace las cosas habituales que a una botnet le gusta, como el DDOS, atacando a todos los dispositivos conectados a internet, o por supuesto, criptominado.

En su lugar, viene con un conjunto bastante rico de características para la extracción de información (sensible), una arquitectura modular capaz de captar y ejecutar otros comandos y ejecutables y todo a través de múltiples capas de comunicación cifrada.

Además, Torii puede infectar una amplia gama de dispositivos y brinda soporte para una amplia gama de arquitecturas de destino, incluyendo MIPS, ARM, x86, x64, PowerPC, SuperH y otros. Definitivamente, uno de los conjuntos más grandes que hemos visto hasta ahora.

Como hemos estado investigando esta cepa, hemos encontrado indicios de que esta operación ha estado funcionando desde diciembre de 2017, tal vez incluso más.

Nos gustaría darle crédito a @VessOnSecurity, quien en realidad tuiteó sobre una muestra de esta cepa que golpeó su telnet Honeypot la semana pasada.

De acuerdo con este investigador de seguridad, los ataques de telnet han estado llegando a su honeypot desde los nodos de salida de Tor, por lo que decidimos nombrar a esta botnet " Torii ".

En esta publicación, describiremos lo que sabemos sobre esta cepa hasta ahora, cómo se está propagando, cuáles son sus etapas y describiremos algunas de sus características.

El análisis aún está en curso y se incluirán más conclusiones en las actualizaciones de las publicaciones del blog.

Ahora, comencemos con el vector de infección.

Análisis del script de shell inicial

La cadena de infección comienza con un ataque telnet en las credenciales débiles de los dispositivos seleccionados, seguido de la ejecución de un script de shell inicial. Esta secuencia de comandos se ve muy diferente de las secuencias de comandos típicas que utiliza el malware IoT, ya que es mucho más sofisticada.

La secuencia de comandos inicialmente intenta descubrir la arquitectura del dispositivo objetivo y luego intenta descargar la carga útil adecuada para ese dispositivo. La lista de arquitecturas que soporta Torii es bastante impresionante: incluye dispositivos basados en x86_64, x86, ARM, MIPS, Motorola 68k, SuperH, PPC - con varios bits de ancho y extensiones. Esto permite a Torii infectar una amplia gama de dispositivos que se ejecutan en estas arquitecturas muy comunes.

El malware usa varios comandos para descargar cargas binarias ejecutando los siguientes comandos: "wget", "ftpget", "ftp", "busybox wget" o "busybox ftpget". Utiliza múltiples comandos para maximizar la probabilidad de que pueda entregar la carga útil.

Si los archivos binarios no se pueden descargar a través del protocolo HTTP con los comandos " wget"  o " busybox wget ", se usará FTP. Cuando se utiliza el protocolo FTP, se requiere autenticación. Las credenciales están bien proporcionadas en el script:

Nombre de usuario: u = "<redacted>" Contraseña: p = "<redacted>"

Puerto para FTP: po = 404

IP del servidor FTP / HTTP: 104.237.218.85 (esta IP aún está activa al momento de escribir esta publicación).

Al conectarse al servidor FTP, hay muchas cosas en marcha:

Haga clic para ver el archivo completo

Entre otras cosas, el servidor contiene registros de los servidores NGINX y FTP, muestras de carga útil, un script de bash que dirige los dispositivos infectados a esta máquina donde se aloja el malware, y más. Discutiremos lo que encontramos en estos registros al final de esta publicación, pero primero echemos un vistazo a todas las muestras que se encuentran allí.

Análisis de la carga útil 1ª etapa (cuentagotas)

Una vez que el script determina en qué arquitectura se está ejecutando el dispositivo de destino, descarga y ejecuta el binario apropiado desde el servidor. Todos estos archivos binarios están en el formato de archivo ELF. Al analizar estas cargas útiles, descubrimos que todas son muy similares y son "simplemente" goteros de la carga útil de la segunda etapa. Lo que es notable es que utilizan varios métodos para hacer que la segunda etapa sea persistente en el dispositivo de destino. Echemos un vistazo más profundo en los detalles a continuación.

Para nuestra descripción, nos centraremos en la muestra x86 con el hash SHA256:

0ff70de135cee727eca5780621ba05a6ce215ad4c759b3a096dd5ece1ac3d378.

Ofuscación de cadena

Primero intentamos desenfocar la muestra, así que profundizamos en algunas de las cadenas de texto para buscar pistas sobre cómo funciona el malware. La gran mayoría de las cadenas de texto en la 1ª y 2ª etapa están cifradas por un simple cifrado basado en XOR y se descifran durante el tiempo de ejecución cuando se necesita una cadena en particular. Puedes usar la siguiente secuencia de comandos IDA Python para descifrar:

Instala el archivo ELF de 2nd Stage

La funcionalidad principal de la primera etapa es instalar otro archivo ELF, el ejecutable de la segunda etapa, que está contenido dentro del primer archivo ELF.

El archivo se instala en una ubicación pseudoaleatoria que se genera al combinar una ubicación predefinida de una lista fija:

• "/ usr / bin"

• "/ usr / lib"

• $ HOME_PATH

• "/ system / xbin"

• "/ dev"

• $ LOCATION_OF_1ST_STAGE

• "/ var / tmp"

• "/ tmp"

y un nombre de archivo de otra lista:

• "Setenvi"

• "Puenteado"

• "Swapper"

• "Natd"

• "Lftpd"

• "Inicio"

• "Unix_upstart"

• "Mntctrd"

• etc.

Poner estos dos elementos juntos crea la ruta del archivo de destino.

Hacer la 2a etapa persistente

Después, el gotero se asegura de que la carga útil de la segunda etapa se ejecute y de que permanezca persistente. Es único en el sentido de que es extraordinariamente exhaustivo en cuanto a cómo logra la persistencia. Utiliza al menos seis métodos para asegurarse de que el archivo permanezca en el dispositivo y siempre se ejecute. Y no solo se ejecuta un método, se ejecuta en todos ellos.

1. Ejecución automática mediante código inyectado en ~ \ .bashrc

2. Ejecución automática a través de la cláusula “@reboot” en crontab

3. Ejecución automática como un servicio "System Daemon" a través de systemd

4. Ejecución automática a través de / etc / init y PATH. Una vez más, se llama a sí mismo "Daemon del sistema"

5. Ejecución automática a través de la modificación de SELinux Policy Management

6. Ejecución automática a través de / etc / inittab

Y, finalmente, ejecuta la ELF interna caída -  la carga útil de la segunda etapa.

Análisis de la carga útil de la segunda etapa (bot)

La carga útil de la segunda etapa es un robot completo capaz de ejecutar comandos desde su maestro (CnC). También contiene otras características tales como técnicas simples de anti-depuración, exfiltración de datos, cifrado de múltiples niveles de comunicación, etc.

Además, muchas de las funciones encontradas en la segunda etapa son las mismas que en la primera, lo que hace que sea muy probable que ambas hayan sido creadas por el mismo autor(es).

El código dentro de la carga útil de la primera etapa es casi idéntico en todas las versiones. Sin embargo, esto no es cierto en el caso de la segunda etapa en la que encontramos diferencias entre los binarios para varias arquitecturas de hardware. Para describir la funcionalidad principal que se puede encontrar en la mayoría de las versiones, volveremos a analizar el código x86 que se encuentra en la muestra con hash SHA256: 5c74bd2e20ef97e39e3c027f130c62f0cfdd6f6e008250b3c5c35ff9647f2abe.

Métodos anti-análisis

Los métodos de análisis de este malware no son tan avanzados como estamos acostumbrados a ver en Windows o en malware para dispositivos móviles, pero están mejorando.

• Utiliza el método anti-análisis simple de un sueño de 60 segundos () después de la ejecución, que probablemente intenta eludir las cajas de arena simples.

• Además, intenta aleatorizar el nombre del proceso a través de la llamada prctl (PR_SET_NAME) a algo como "\ [[az] {12,17} \]" (expresión regular) para evitar la detección de nombres de procesos en la lista negra.

• Finalmente, los autores intentan dificultar el análisis eliminando los símbolos de los ejecutables. Cuando descargamos por primera vez las muestras del servidor mencionado anteriormente 104.237.218.85, todas contenían símbolos, lo que facilitó su análisis. Es interesante observar que unos días más tarde, estos archivos fueron reemplazados por sus versiones eliminadas. No se encontraron otras diferencias entre estas dos versiones, lo que nos lleva a creer que los autores toman medidas continuas para proteger aún más sus ejecutables contra el análisis.

Servidores CnC

Como ya dijimos, este componente es un bot que se comunica con un servidor CnC maestro. Las direcciones de los CnC están nuevamente cifradas por el cifrado basado en XOR mencionado anteriormente. Parece que cada versión Torii contiene 3 direcciones CnC. La campaña que se está ejecutando actualmente intenta obtener comandos de los servidores CnC que se ejecutan en:

• top.haletteompson.com

• cloud.tillywirtz.com

• trade.andrewabendroth.com

Intenta comunicarse con el primer dominio de la lista y pasa al siguiente si falla. En caso de error, también intenta resolver el nombre de dominio a través de Google DNS 8.8.8.8.

Resolución de nombre de dominio CnC

Estos tres nombres de dominio se han resuelto en IP 66.85.157.90 desde el 15 de septiembre de 2018. Algunos otros dominios alojados en la misma IP también son bastante sospechosos:

cloud.tillywirtz.com 
dushe.cc 
editor.akotae.com 
press.eonhep.com 
web.reeglais.com 
psoriasiafreelife.win 
q3x1u.psoriasiafreelife.win 
server.blurayburnersoftware.com 
top.haletteompson.com 
trade.andrewabendroth.com 
www.bubo. cc www.dushe.cc

El hecho de que tantos dominios de apariencia extraña se alojen en una dirección IP genera preocupación. Además, los nombres de dominio CnC se resolvieron a una dirección IP diferente (184.95.48.12) antes de eso.

(Historial de resolución de nombres DNS codificados en la muestra)

Un poco más de excavación arrojó otro conjunto de muestras ELF pertenecientes a Torii con tres direcciones CnC diferentes:

• prensa.eonhep.com

• editor.akotae.com

• web.reeglais.com

Todos se resolvieron con la misma IP (184.95.48.12) en el pasado y, por ejemplo, "press.eonhep.com" usaba esta IP desde el 8 de diciembre de 2017 . Por lo tanto, creemos que esta cepa existe desde al menos diciembre de 2017 y posiblemente más.

Comunicacion cnc

La segunda etapa se comunica con estos servidores CnC a través del puerto TCP 443, así como con otras capas de cifrado. Es interesante observar que utiliza el puerto 443 como un engaño, ya que no se comunica con TLS, pero aprovecha el uso común de este puerto para el tráfico HTTPS. Cada mensaje (incluidas las respuestas) forma una estructura a la que llamamos "sobre de mensaje" y cada sobre está encriptado AES-128 y hay una suma de comprobación MD5 del contenido para garantizar que no se haya modificado o dañado. Además, cada sobre contiene un flujo de mensajes donde cada mensaje está cifrado por un simple cifrado basado en XOR, que es diferente al que se usa para ofuscar las cadenas. No es tan fuerte como parece que las claves de descifrado se incluyen en la comunicación.

Algoritmo utilizado para el cifrado de mensajes CnC

Torii también exfiltra la siguiente información al conectarse a un servidor CnC:

• Nombre de host

• Identificacion de proceso

• Camino al ejecutable de la segunda etapa

• Todas las direcciones MAC que se encuentran en / sys / class / net /% interface_name% / address + su hash MD5: esto forma algún tipo de ID de víctima único, lo que permite que el mal actor haga huellas dactilares y catalogue los dispositivos con mayor facilidad. También se almacena en archivos locales con nombres extraños tales como GfmVZfJKWnCheFxEVAzvAMiZZGjfFoumtiJtntFkiJTmoSsLtSIvEtufBgkgugUOogJebQojzhYNaqyVKJqRcnWDtJlNPIdeOMKP, VFgKRiHQQcLhUZfvuRUqPKCtcrjmhtKcYQorAWhqAuZuWfQqymGnWiiZAsljnyNlocePAOHaKHvGoNXMZfByomZqEMbtkOEzQkQq, XAgHrWKSKyJktzLCMcEqYqfoeUBtgodeOjLgfvArTLeOkPSyRxqrpvFWRhRYvVcLeNtMKTdgFhwrypsRoIiDeObVxTTuOVfSkzgx, etc.

• Los detalles encontrados por uname () llaman, incluyendo sysname, version, release, y machine.

• Salidas de los siguientes comandos diseñados para obtener aún más información sobre el dispositivo de destino:

id 2> / dev / null 
uname -a 2> / dev / null 
whoami 2> / dev / null 
cat / proc / cpuinfo 2> / dev / null 
cat / proc / meminfo 2> / dev / null 
cat / proc / version 2> / dev / null 
cat / proc / partitions 2> / dev / null 
cat / etc / * release / etc / issue 2> / dev / null

Comandos CnC

Al analizar el código, encontramos que el componente bot se está comunicando con el CnC con el sondeo activo en un bucle sin fin, siempre preguntando a su CnC si hay comandos para ejecutar. Después de recibir un comando, responde con los resultados de la ejecución del comando. Cada sobre de mensaje tiene un valor que especifica qué tipo de comando trae. El mismo valor se utiliza para la respuesta. Hemos descubierto los siguientes tipos de comandos:

• 0xBB32 - Almacena un archivo de CnC a una unidad local :

◦ Recibir:

1. Ruta de archivo donde almacenar contenido de CnC

2. Contenido

3. Suma de control MD5 de contenido

◦ Respuesta:

1. Ruta del archivo donde se almacenó el archivo

2. Código de error

• 0xA16D - Recibir el valor del tiempo de espera que se utilizará para el sondeo CnC :

◦ Recibir:

1. DWORD con la cantidad de minutos para dormir entre los contactos CnC

◦ Respuesta:

1. Mensaje con el código 66

• 0xAE35 - Ejecuta un comando dado en un intérprete de shell deseado y envía las salidas a CnC :

◦ Recibir:

1. Comando para ejecutar en shell (sh -c "exec COMMAND")

2. WORD con tiempo de espera de ejecución en segundos (máximo 60 segundos)

3. Cadena con una ruta al intérprete de shell (opcional)

◦ Respuesta:

1. Cadena con salidas (stdout + stderr) de ejecución de comando

• 0xA863 - Almacena un archivo desde CnC a una ruta determinada, cambia sus marcas a "rwxr-xr-x" para hacer que sea ejecutable y luego ejecútalo :

◦ Recibir:

1. Ruta de archivo donde almacenar contenido desde CnC

2. Contenido

3. Suma de control MD5 de contenido

◦ Respuesta:

1. Ruta del archivo donde se almacenó el archivo

2. Código de retorno de la ejecución de ese archivo

• 0xE04B - Verifica que el archivo dado exista en un sistema local y devuelva su tamaño :

◦ Recibir:

1. Filepath para comprobar

◦ Respuesta:

1. Ruta de archivo

2. Tamaño del archivo

• 0xF28C - Leer N bytes del desplazamiento O del archivo F seleccionado y enviarlos a CnC :

◦ Recibir:

1. Archivo ruta al archivo (F) para leer desde

2. QWORD offset (O) donde empezar a leer

3. Número DWORD (N) de bytes para leer

◦ Respuesta:

1. Contenido del archivo

2. Compensar

3. Tamaño de bytes leídos

4. Suma de comprobación MD5 del contenido leído

• 0xDEB7 - Eliminar un archivo especificado

◦ Recibir:

1. Nombre de un archivo para eliminar

◦ Respuesta:

1. Código de error

• 0xC221 - Descargar un archivo desde la URL dada

◦ Recibir:

1. Ruta a un archivo de tienda

2. URL

◦ Respuesta:

1. Ruta de archivo

2. URL

• 0xF76F: obtener la dirección de un nuevo servidor CnC y comenzar a comunicarse con él.

◦ Recibir:

1. ?

2. Nuevo nombre de dominio

3. Nuevo puerto

4. ?

◦ Respuesta:

1. Repetir la información recibida.

• 0x5B77, 0x73BF , 0xEBF0, y probablemente otros códigos : algún tipo de comunicación para hacer ping u obtener un latido en el dispositivo de destino para asegurar al compañero de comunicación que el canal de comunicación está funcionando) :

◦ Recibir:

1. Todo lo recibido es ignorado.

◦ Respuesta:

1. Repetir la información recibida.

Análisis del sm_packed_agent

Mientras investigábamos el servidor, encontramos otro binario interesante que pudimos obtener del servidor FTP que se llama "sm_packed_agent". No tenemos ninguna evidencia de que se haya utilizado en el servidor, pero su versatilidad sugiere que podría usarse para enviar cualquier comando remoto deseado al dispositivo de destino. Contiene una aplicación escrita por GO empaquetada usando UPX cuando está desempaquetada, tiene algunas cadenas interesantes que sugieren que tiene capacidades de servidor:

Debajo, utiliza las siguientes bibliotecas de terceros: Reutilización de código

https://github.com/shirou/ gopsutil / host 

https://github.com/shirou/gopsutil/cpu

https://github.com/shirou/gopsutil/mem

https://github.com/shirou/gopsutil/ net

Posible nombre del código fuente:

/go/src/Monitor_GO/agent/agent.go

/go/src/Monitor_GO/sm_agent.go

Algunas de estas bibliotecas están abusando de una licencia BSD, que requiere la redistribución del aviso de copyright. Al parecer, los autores de Torii no se preocupan por la infracción de derechos de autor.

Funcionalidad

La funcionalidad de sm_agent es la siguiente:

• Toma un parámetro en cmdline -p con número de puerto

• Inicializa criptografía, carga TLS y teclas + cert.

• Crea servidor y escucha conexión TLS.

• Espera comandos codificados en formato BSON

• El controlador de comandos en el interior conoce estos comandos:

◦ 1: Monitor_GO_agent__Agent_GetSystemInfo

◦ 2: Monitor_GO_agent__Agent_GetPerformanceMetrics

◦ 7: Monitor_GO_agent__Agent_ExecCmdWithTimeout Este comando parece ser capaz de ejecutar cualquier comando de OS arbitrario leído desde la carga de BSON.

Encriptación TLS, certificados y claves:

• El agente utiliza el cifrado de flujo ChaCha20-Poly1305 para TLS

• Llaves y certificados en el mismo directorio.

• Certificado autofirmado de autoridad ca.crt con el nombre Mayola Mednick

• client.crt emitido por ca.crt para Dorothea Gladding

• server.crt + server.key emitido por ca.crt para Graham Tudisco

Los certificados son autofirmados y obviamente usan nombres falsos.

Start-agent.sh

Este script es para eliminar cualquier instancia previa de inicio sm_packed_agent y ejecutarlo en el puerto TCP 45709 y volver a ejecutarlo en caso de que falle.

Un script que se ejecuta y sigue ejecutando sm_packed_agent

Todavía no se sabe cómo los autores Torii están utilizando este servicio, pero es increíblemente versátil y podría utilizarse para ejecutar cualquier comando en el dispositivo. Y debido a que esta aplicación está escrita en GO, se puede volver a compilar fácilmente para ejecutarse en prácticamente cualquier arquitectura. Teniendo en cuenta que este archivo se ejecuta en una máquina de distribución de malware, es muy posible que sea una puerta trasera o incluso un servicio para orquestar máquinas múltiples.

Análisis de los registros del servidor 104.237.218.85

Finalmente, echamos un vistazo a los registros que encontramos tanto para el servidor Nginx como para el servidor FTP. Dicho registro de acceso puede ayudarnos a comprender cuántos clientes realmente fueron infectados por Torii o intentaron descargarlo.

Mientras escribimos este blog, los autores de Torii ya han deshabilitado el registro de FTP y Nginx (más sobre esto más adelante), pero al mirar los registros disponibles, podemos generar algunas estadísticas simples.

Un total de 206 direcciones IP únicas conectadas al servidor los días 7, 8, 19 y 20 de septiembre, según los registros del servidor.

Access-2018-09-07.log - 54 direcciones IP únicas

Acceso-2018-09-08.log - 20

Acceso-2018-09-19.log - 189

Acceso-2018-09-20.log - 10

¡Parece una IP 38.124.61.111 conectada al servidor 1 056 393 veces!

Al examinar los registros, parece que alguien realmente ejecutó DirBuster-1.0-RC1, tratando de descubrir qué está pasando. Brute force DirBuster se utiliza para adivinar directorios / nombres de archivos en el servidor web y genera una gran cantidad de solicitudes. Es bastante desafortunado si este escaneo se originó de un investigador, ya que hay enfoques más elegantes en el caso de un malware sofisticado como Torii.

Al escanear los puertos de IP 38.124.61.111, podemos ver que hay algunos puertos abiertos:

En el puerto 27655, hay una pancarta SSH que dice:

"SSH-2.0-OpenSSH_7.4p1 Raspbian-10 + deb9u3" Parece que esta caja ejecuta Raspbian. Si estás detrás de esto, escríbenos.

Otros registros que están disponibles para nosotros son los registros del servidor FTP.

Hay algunos clientes que conectaron y descargaron algunos archivos que ya no están en el servidor FTP:

Sáb 8 de septiembre 08:31:24 2018 1 128.199.109.115 6 /media/veracrypt1/nginx/md/zing.txt b _ or md ftp 0 * c

Según los registros que pudimos analizar, un total de 592 clientes únicos estaban descargando archivos de este servidor en un período de unos pocos días. Es importante recordar que una vez que el dispositivo de destino recibe la carga útil, deja de conectarse al servidor de descarga y se conecta al servidor CnC. Por lo tanto, es probable que veamos una instantánea de los nuevos dispositivos que se reclutaron en esta botnet durante el período de tiempo en el que tenemos archivos de registro.

Además, hay 8 clientes que usaban el servidor HTTP y el servidor FTP, lo que podría ser el caso si la descarga con HTTP fallara por algún motivo, o si los autores Torii estaban probando la funcionalidad del script bash o la configuración del servidor.

No podemos especular sobre lo que no tenemos evidencia, pero este servidor podría ser solo uno de una serie de servidores que infectan nuevos dispositivos de destino, y solo una investigación más profunda revelará el verdadero alcance de esta red de bots. Dado el nivel de sofisticación del malware que investigamos, parece probable que esté diseñado para mapear y controlar una gran cantidad de dispositivos diversos.

Conclusión

A pesar de que nuestra investigación continúa, está claro que Torii es un ejemplo de la evolución del malware IoT, y que su sofisticación está por encima de todo lo que hemos visto antes. Una vez que infecta un dispositivo, no solo envía una gran cantidad de información sobre la máquina en la que reside en el CnC, sino que, al comunicarse con el CnC, permite a los autores de Torii ejecutar cualquier código o entregar cualquier carga útil al dispositivo infectado. Esto sugiere que Torii podría convertirse en una plataforma modular para uso futuro. Además, debido a que la carga útil en sí no está buscando otros posibles objetivos, es bastante sigilosa en la capa de red.

Estén atentos para los seguimientos.

IoC

CnC

top.haletteompson.com

Nube.tillywirtz.com

trade.andrewabendroth.com

prensa.eonhep.com

editor.akotae.com

web.reeglais.com

IP

184.95.48.12

104.237.218.82

104.237.218.85

66.85.157.90

SHA256 
[haz clic aquí para ver los hashes de SHA256]