Un investigador y un …


Cuando Larry Cashdollar instaló un honeypot en una imagen de Docker, encontró un comportamiento que fue más esclarecedor de lo que había imaginado.

(imagen de jag_cz, a través de Adobe Stock)

(imagen de jag_cz, a través de Adobe Inventory)

A veces no aplastas las moscas que zumban alrededor de tu mesa. A veces los estudias para poder aplastar mejor la próxima ronda de moscas. Eso es lo que hizo Larry Cashdollar, investigador principal de Akamai, cuando los piratas informáticos pulularon un honeypot que desplegó a principios de este año. Y lo que vio fueron tendencias en la piratería que podrían hacer la vida un poco más difícil para las futuras moscas cibernéticas.

«Había configurado un honeypot que era más o menos una imagen de Docker que hice para parecer un servidor world-wide-web SSH», dice Cashdollar. Sin embargo, más que eso, trató de hacer que la imagen se pareciera tanto a un servidor Linux completo como fuera posible. Period importante para este poco de investigación que los atacantes no se dieran cuenta de que habían atacado con éxito un honeypot.

«Lo que quería que hicieran era iniciar sesión, pensar que es un host Linux comprometido o un sistema Docker comprometido, luego permanecer allí y soltar sus warez y hacer lo que sea que van a hacer con un sistema una vez comprometidos «, explica.

Lo que descubrió Cashdollar fue que los atacantes tenían patrones en cómo atacaron el honeypot, así como patrones en lo que hicieron con el sistema comprometido una vez que estuvieron dentro.

Uno de los patrones que Cashdollar notó fue que ciertas combinaciones de nombre de usuario / contraseña estaban asociadas con acciones maliciosas específicas. en un publicación de blog sobre su investigación, escribió: «Las combinaciones de inicio de sesión de root: admin, root: root, oracle: oracle usarían invariablemente la imagen del acoplador como un proxy SOCKS5 a través de SSHd».

Ese proxy SOCKS5 transmitiría contenido de Twitch, Google, Netflix y otros proveedores de contenido. Escribió que un colega le informó que la razón de al menos uno de estos, la transmisión de Twitch, probablemente era para rellenar el recuento de vistas de transmisión para uno o más jugadores.

Sin embargo, antes de que las plataformas comenzaran a actuar como proxy para la transmisión de contenido, se realizaron varios pasos.

Primero, dice, el código malicioso intentó agregar un puñado de nuevos usuarios. Luego buscó cambiar la contraseña de root e instalar un trabajo cron para volver a ejecutar el script de infección de forma standard y, por lo tanto, establecer la persistencia.

Una de las cosas nuevas que Cashdollar vio que hacía el código de infección fue tratar de hacer que un directorio específico sea inmutable modificando el atributo de cambio para que ni siquiera el usuario raíz legítimo pudiera hacer cambios a los usuarios y contraseñas. Él dice que esto funcionará (y requiere un programa de utilidad específico para cambiar), pero no es una táctica que haya visto en otros ataques.

Después de establecer el management y la persistencia, el código de conexión verifica cuántas CPU tiene el sistema y, en foundation a eso, puede cargar un paquete de criptominer.

Mientras observaba las rutinas automatizadas de la carga maliciosa haciendo su trabajo, Cashdollar notó un comportamiento repetitivo: el malware haría una consulta saliente usando el puerto 3309 (comúnmente usado para comunicaciones punto a punto entre bases de datos Oracle) usando un servidor específico de DNS de Google (en 8.8.8.8) para resolver una dirección única y específica. La mayoría del malware, dice, trabaja mucho más duro para ofuscar la dirección de su servidor de comando y handle (C&C).

Es importante tener en cuenta, dice Cashdollar, que más de un actor malicioso estaba trabajando en el honeypot. En otro comportamiento inusual, dice, los dos actores principales no se esforzaron por buscar otra actividad maliciosa, algo que muchos trozos de malware hacen como una de sus primeras actividades. En cambio, cada pieza de malware se concentró en su propia actividad, y parecía no importarle lo que alguien más estaba haciendo en el sistema objetivo.

Cuando se le preguntó cuánto tiempo le tomó al ataque tener éxito, Cashdollar dijo que el contacto inicial para la persistencia tomó unos pocos segundos. El siguiente conjunto de preguntas a responder involucra el momento de los ataques. Cashdollar dice que los ataques parecieron venir en oleadas.

«Me parece que hay una mayor actividad a ciertas horas del día, y aún no he descubierto cuándo es eso», dice.

Contenido relacionado:

Curtis Franklin Jr. es editor sénior en Dark Studying. En este puesto, se centra en la cobertura de productos y tecnología para la publicación. Además, trabaja en programación de audio y movie para Dark Studying y contribuye a actividades en Interop ITX, Black Hat, INsecurity y … Ver biografía completa

Más tips





Enlace a la noticia primary