En el resumen de esta semana, CTI analiza una campaña en la que los autores de las amenazas intentaron desplazarse lateralmente a un entorno en la nube a través de una instancia de SQL Server. A continuación, CTI investiga un cambio en el método de distribución del malware ShellBot, que suele instalarse en servidores SSH de Linux mal gestionados. Asimismo, se incluye un análisis de la última campaña en la que los autores de amenazas están haciendo un uso indebido de los «Smart Links» de LinkedIn en ataques de phishing de tipo « » para eludir las medidas de protección y evitar ser detectados.
1. Los autores de amenazas intentan desplazarse lateralmente desde el servidor SQL hacia la nube
Microsoft ha descubierto recientemente una campaña en la que los autores de las amenazas intentaban desplazarse lateralmente a un entorno en la nube (se abre en una nueva pestaña) a través de una instancia de SQL Server. Aunque Microsoft ya había observado esta técnica anteriormente en otros servicios en la nube, como máquinas virtuales y clústeres de Kubernetes, esta es la primera vez que la detecta en un servidor SQL.
El ataque observado comenzó cuando el autor de la amenaza aprovechó una vulnerabilidad de inyección SQL en una aplicación del entorno de la víctima. El actor malintencionado obtuvo acceso y permisos elevados en una instancia de Microsoft SQL Server implementada en una máquina virtual de Azure y utilizó dichos permisos para intentar desplazarse lateralmente hacia otros recursos en la nube, haciendo un uso indebido de la identidad en la nube del servidor.
Movimiento lateral basado en la nube: una amenaza creciente
A medida que las organizaciones se pasan a la nube, están surgiendo cada vez más tipos de ataques basados en la nube. Los actores maliciosos están tomando nota de este cambio y están encontrando nuevos vectores para llevar a cabo movimientos laterales desde entornos locales hacia entornos en la nube.
Un método habitual de movimiento lateral en entornos en la nube consiste en el uso indebido de identidades vinculadas al recurso en la nube. Muchos servicios, como Azure, utilizan identidades gestionadas para asignar identidades a distintos recursos en la nube. A continuación, estas identidades se utilizan para la autenticación con otros recursos o servicios en la nube. Si bien esto ofrece un cierto grado de comodidad, abre la puerta a que los autores de amenazas exploten nuevos vectores de ataque potenciales.
Técnica conocida, nuevo entorno
Microsoft señala que es la primera vez que se ha observado un intento de desplazamiento lateral desde una instancia de SQL Server a un entorno en la nube. No obstante, este ataque incluyó numerosas actividades que suelen darse en los ataques a servidores SQL.
El vector de acceso inicial fue un ataque de inyección SQL que permitió al autor de la amenaza ejecutar consultas en el servidor SQL, una táctica bastante habitual. Además, los autores del ataque ejecutaron varias sentencias SQL para recabar datos sobre el servidor, las bases de datos y la configuración de la red. Esta es otra actividad habitual.
Según Microsoft, la aplicación afectada por la vulnerabilidad de inyección SQL disponía de permisos elevados, lo que otorgaba al autor de la amenaza un nivel de acceso similar. Estos permisos elevados se utilizaron para activar el comando xp_cmdshell, que sirve para ejecutar comandos del sistema operativo a través de una consulta SQL. Xp_cmdshell está desactivado de forma predeterminada para evitar que se aproveche para fines maliciosos. Una vez que el autor de la amenaza activó esta función, utilizó sus permisos para modificar la configuración de SQL y ejecutar varios comandos.
El autor del ataque ejecutó manualmente una serie de comandos del sistema operativo para poner en marcha las fases restantes del ataque. El uso de xp_commandshell permitió al autor de la amenaza actuar como si dispusiera de un shell en el host. El autor de la amenaza utilizó métodos sencillos para recopilar datos antes de descargar varios archivos ejecutables y scripts de PowerShell. Para garantizar la persistencia, el autor de la amenaza utilizó una tarea programada para ejecutar un script de puerta trasera e intentó extraer las claves de registro SAM y SECURITY con el fin de obtener credenciales.
Para la exfiltración de datos, el autor de la amenaza utilizó un servicio de acceso público denominado webhook[.]site. Este servicio es una plataforma gratuita que permite inspeccionar, depurar y recibir solicitudes HTTP y correos electrónicos entrantes. Este método de exfiltración de datos permitió al autor de la amenaza actuar de forma discreta al transmitir el tráfico saliente, ya que este servicio podría considerarse legítimo.
Los autores del ataque intentaron utilizar la identidad en la nube de la instancia del servidor SQL accediendo al IMDS y obteniendo la clave de acceso de dicha identidad. IMDS es un servicio web RESTful que proporciona información sobre la máquina virtual, incluido el token de identidad. El token de identidad es un token web JSON (JWT) que contiene las reclamaciones y la firma de la identidad. Con este token de identidad, el actor malintencionado puede realizar diversas operaciones en los recursos en la nube a los que tiene acceso la identidad en la nube. Esto incluye el movimiento lateral en el entorno de la nube.
Es importante reiterar que se trató únicamente de un intento y que Microsoft no tiene indicios de que se haya producido un movimiento lateral con éxito.
Comentarios de los analistas del equipo de inteligencia sobre amenazas cibernéticas de Tanium
Aunque los autores de la amenaza no lograron desplazarse lateralmente, esta actividad pone de manifiesto cómo los ciberdelincuentes prueban continuamente nuevas tácticas para adaptarse a la transición a la nube.
Este intento pone de relieve la importancia de proteger adecuadamente las identidades en la nube y de aplicar prácticas basadas en el principio del privilegio mínimo, tanto en las instalaciones como en la nube. Microsoft aún no ha facilitado ningún indicador de compromiso (IOC) relacionado con esta actividad, pero el CTI seguirá atento a cualquier información adicional.
2. ShellBot evita ser detectado en los ataques contra servidores SSH de Linux
Investigadores del Centro de Respuesta a Emergencias de Seguridad de AhnLab ( ) (se abre en una nueva pestaña) (ASEC) han descubierto recientemente un cambio en el método de distribución del malware ShellBot (se abre en una nueva pestaña) , que suele instalarse en servidores SSH de Linux mal gestionados.
Los autores de las amenazas siguen el mismo procedimiento general, pero la URL descargada para instalar el malware ha pasado de ser una dirección IP convencional a un valor hexadecimal.
¿Qué es ShellBot?
ShellBot —o PerlBot— es un malware de tipo bot de ataques DDoS desarrollado en Perl. ShellBot es un malware bastante antiguo que todavía se utiliza hoy en día para lanzar ataques contra sistemas Linux. Se caracteriza por utilizar el protocolo IRC para comunicarse con su servidor de mando y control (C2). El malware se instala en sistemas con credenciales débiles después de que el autor de la amenaza haya buscado sistemas con el puerto 22 abierto.
El malware utiliza una lista de credenciales SSH conocidas para llevar a cabo un ataque de diccionario contra estos servidores e implementar la carga útil. ShellBot puede recibir órdenes del C2 , lo que le permite llevar a cabo ataques DDoS y sustraer información. A lo largo de los años se han descubierto diversas versiones de ShellBot, algunas de las cuales cuentan con capacidades similares a las de una puerta trasera que permiten el acceso a un shell inverso y la carga de archivos arbitrarios. En un caso, se utilizó ShellBot para distribuir programas de minería de criptomonedas a través de un compilador de scripts de shell.
Casos anteriores de ShellBot
Los atacantes comienzan por escanear los sistemas que tienen el puerto 22 abierto y el protocolo SSH activo. Utilizan una lista de credenciales SSH de uso habitual para iniciar su ataque.
Entre las numerosas variantes de ShellBot que circulan, hay una conocida como DDoS PBot v2.0. El autor de la amenaza que ha estado utilizando esta variante en sus ataques emplea sistemáticamente el nombre «dred» durante la instalación del malware.
Entre las funciones que admite DDoS PBot v2.0 se incluyen:
- Información generada por el sistema infectado
- Mostrar información sobre la versión
- Comandos de control de IRC
- Comandos DDoS (TCP, UDP, HTTP, inundación SQL y otros)
- Comandos de ataque (escaneo de puertos, shell inverso, descarga de archivos y otros)
Últimos ataques de ShellBot
En September 2023, los investigadores confirmaron que el mismo actor malicioso mencionado anteriormente estaba instalando ahora ShellBot mediante direcciones IP hexadecimales.
Tras iniciar sesión correctamente en una cuenta, el autor de la amenaza utilizó los siguientes comandos para instalar ShellBot. Estos comandos son idénticos a los de los casos anteriores, pero utilizan valores hexadecimales para la dirección IP.
La dirección representada en hexadecimal como 0x2763da4e corresponde a 39.99.218[.]78 , mientras que 0x74cc54bd corresponde a 116.204.84[.]189. Gracias al uso de curl para la descarga y a su capacidad para admitir valores hexadecimales, al igual que los navegadores web, ShellBot puede descargarse correctamente en un entorno de sistema Linux y ejecutarse mediante Perl.
Comentarios de los analistas del equipo de inteligencia sobre amenazas cibernéticas de Tanium
La instalación de malware mediante direcciones IP hexadecimales constituye un intento de eludir las firmas de detección basadas en URL. Sin embargo, no es la primera vez que los investigadores observan el uso de esta táctica. Las campañas de spam anteriores de Emotet utilizaban direcciones IP tanto en formato octal como hexadecimal para evitar ser detectadas.
Esta táctica no ha gozado de gran popularidad en los últimos meses, por lo que resultará interesante ver si la adopción de ShellBot despertará el interés de otros actores maliciosos.
3. Los ataques de «Smart Links» tienen como objetivo las cuentas de Microsoft
Los autores de amenazas siguen haciendo un uso indebido de los «Smart Links» de LinkedIn (se abre en una nueva pestaña) en ataques de phishing para eludir las medidas de protección y evitar ser detectados. La última oleada de ataques observada por Cofense tuvo como objetivo las credenciales de cuentas de Microsoft Office de , (se abre en una nueva pestaña),y en diversos sectores.
¿Qué son los «Smart Links» de LinkedIn?
Las cuentas empresariales utilizan los «Smart Links» de LinkedIn para difundir contenidos y realizar un seguimiento de la interacción. El Smart Link utiliza el dominio legítimo de LinkedIn, seguido de un parámetro de código y un identificador alfanumérico de 8 caracteres.
Los enlaces inteligentes maliciosos también pueden incluir otros datos, como direcciones de correo electrónico de las víctimas ocultas. Un kit de phishing leerá el correo electrónico de la víctima adjunto al «Smart Link» y rellenará automáticamente un formulario malicioso para dar una apariencia de legitimidad a una página de inicio de sesión de Microsoft creada con fines de phishing.
La última campaña en la que se utilizan los «Smart Links»
El uso de «Smart Links» en campañas de phishing no es algo nuevo, pero tampoco es algo que se vea a diario. Cofense ha observado que los «Smart Links» eluden las pasarelas de correo electrónico seguras (SEG) y otras soluciones de seguridad para el correo electrónico, ya que el enlace utiliza el dominio de confianza de LinkedIn. Los correos electrónicos de esta última campaña utilizan asuntos bastante genéricos relacionados con temas financieros, de recursos humanos, de documentación, de seguridad, etc.
Cuando el usuario hace clic en el enlace del correo electrónico de phishing, se le redirige a la página de phishing, donde se le indica que inicie sesión con sus credenciales de Microsoft Office. La página de phishing rellenará automáticamente el campo del nombre de usuario con la dirección de correo electrónico de la víctima.
Cofense observó que esta campaña abarcaba varios sectores, siendo el financiero y el manufacturero los más afectados. La campaña parece tener un carácter bastante oportunista, ya que los autores de las amenazas pretenden recabar el mayor número posible de credenciales sin centrarse en ningún sector concreto.
Comentarios de los analistas del equipo de inteligencia sobre amenazas cibernéticas de Tanium
Los investigadores ya habían observado anteriormente los «Smart Links» de LinkedIn en diversas campañas de phishing, aunque no con mucha frecuencia. Tal y como explica Cofense, esta campaña destacó por ser una anomalía, ya que incluía más de 80 «Smart Links» únicos que utilizaban páginas empresariales de LinkedIn que habían sido comprometidas.
Aunque puede que en esta última campaña no haya ninguna técnica, táctica o procedimiento (TTP) que suponga una gran novedad, sí que reitera que la seguridad del correo electrónico tiene sus límites y lo esencial que resulta que los empleados reciban formación y sensibilización sobre el phishing.
¿Tiene alguna información sobre estas historias que desee compartir? Visite , el foro de debate de Tanium , y inicie una conversación.
Si desea ampliar información, consulte nuestros últimos resúmenes de inteligencia sobre ciberamenazas de :.
