En ataques de cryptomining pasados, los shell scripts maliciosos se usaban típicamente como downloaders. Sin embargo, casos recientes muestras que ahora sirven otros propósitos como el robo de datos sensibles.
__________________________________________________________________
Recientemente descubrimos nuevos ataques donde, de nuevo, los actores maliciosos usaron shell scripts para realizar actividades ilícitas. Estos scripts vinieron de una imagen en un repositorio público de containers; los usuarios deben estar conscientes de los riesgos de seguridad que implican correrlas, ya que pueden contener elementos maliciosos como backdoors. Revisando los ataques previos, estos scripts maliciosos se usaron típicamente para desplegar cryptominers. Pero casos recientes que involucran estas muestras destacan cómo se desarrollan estos scripts y cómo pueden servir otros propósitos además de ser downloaders para cryptominers.
Basándonos en sus URLs de comando y control, algunas strings, cryptokeys y el lenguaje usado en las muestras, hemos deducido que este último ataque proviene del arsenal de TeamTNT.
Es shell script malicioso usado aquí fue desarrollado en Bash. Comparado con ataques similares pasados, la técnica de desarrollo fue mucho más refinada para este script; no había líneas sin fin de código y las muestras estaban bien escritas y organizadas por función con nombres descriptivos.
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/malicious-shell-script-steals-cloud-credentials/Figure-1-Code-snippets-showing-functions.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″ width=”315″ height=”469″]
Figura 1. Muestra de código y sus funciones
Las primeras funciones detonadas por el shell script preparan el ambiente, asegurándose de que las siguientes fases van a tener los recursos, herramientas y poder de cómputo necesario, entre otros. También revisa la presencia de soluciones de seguridad.
El shell script también descarga algunas herramientas de greyware que se usarán en el futuro para buscar otros blancos. Estas herramientas llevan a cabo escaneo y mapeo que se utilizarán para localizar nuevas APIs vulnerables.
Después de que el ambiente está configurado, el shell script entonces busca la información sensible, obtiene una copia y sube todo a un servidor C&C.
Esta nueva muestra roba credenciales de APIs de Docker también, lo cual es un elemento interesante de este ataque.
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/malicious-shell-script-steals-cloud-credentials/Figure-2-Stealing-and-exfiltration-of-Docker-API-credentials.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 2. Muestra de código mostrando el robo y la exfiltración de credenciales de APIs de Docker
En el tiempo entre que se roban las credenciales y se despliega el cryptominer, el script deja otra muestra embebida y codificada como base64. Esto es para crear un nuevo usuario en el sistema, con permisos sudo y un SSH-RSA-key para asegurar que se pueden conectar a la máquina infectada y mantener el acceso.
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/malicious-shell-script-steals-cloud-credentials/Figure-3-User-Creation.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 3. Muestras de código mostrando la creación de un usuario para mantener el acceso
Solamente después de que todos estos pasos se completan es que se descarga el cryptominer, desplegado bajo un nombre y PATH “sigilosos” y después se ejecuta.
Un último paso agregado recientemente a este nuevo ataque despliega un shell inverso, como se escribe en un blog anterior.
Hasta ahora sólo se han identificado como blancos de este ataque plataformas de containers. La imagen de container que contiene todas las muestras maliciosas fue creada recientemente, con la cuenta de las descargas alcanzando 2,000 antes de que el usuario y la imagen fueran eliminados.
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/malicious-shell-script-steals-cloud-credentials/Figure-4-Container-2K-screenshot.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 4. Screenshot de la imagen de container que contenía las muestras maliciosas
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/malicious-shell-script-steals-cloud-credentials/Figure-5-User-and-image-were-taken-down.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 5. Usuario e imagen eliminados
Las muestras de este ataque recientemente descubierto también fueron halladas con dos nuevas rutinas no previamente vistas en ataques de TeamTNT. En las muestras que habíamos visto antes, la rutina solamente revisa archivos de credenciales en la máquina antes de subirlos. en esta nueva muestra, los desarrolladores agregaron rutinas; la primera solicita el servicio de metadatos de AWS e intenta obtener las credenciales desde ahí. Esto solo sucede conforme los ataques puedan correr el script y, ya que están en la instancia debido a una imagen de Docker con un backdoor que está corriendo, no hay una técnica especial que se utiliza para acceder al servicio de metadatos de instancias (IMDS). Por default, ningún rol está ligado a una instancia y estas credenciales solamente tendrán los permisos que el cliente otorgó. los clientes deberían seguir el principio del menor privilegio si deciden otorgar permisos a un rol de instancia.
La segunda rutina agregada revisa las variables del ambiente para buscar credenciales de AWS; si estas se encuentran presentes se suben al servidor de C&C.
[image url=”https://www.trendmicro.com/content/dam/trendmicro/global/en/research/21/a/malicious-shell-script-steals-cloud-credentials/Figure-6-Code-snippet-showing-stealing-and-exfiltration-of-AWS-credentials.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]
Figura 6. muestra el código mostrando el robo y exfiltración credenciales de AWS
Aunque la fuente de este ataque fue una imagen maliciosa de contenedor, los scripts de la infección no distinguen donde están corriendo, infectando cualquier sistema operativo *nix (Linux, Unix) para recolectar la información de metadatos que el malware debe correr en el alcance de una instancia.
Conclusión
Ataques como el incidente descrito en este texto, destaca la importancia de la vigilancia en la protección de los sistemas contra el compromiso; los usuarios deben tener en cuenta que si están corriendo una imagen al azar, deben tener cuidado de la posibilidad de que un actor malicioso haya agregado elementos maliciosos como backdoors.
Además, aunque parece que el número de variantes de malware de criptomonedas incrementa rápidamente, también parece que los actores maliciosos que despliegan los ataques de minería no están interesados solamente en ella. Algunos de los primeros ataques de este tipo que descubrimos en el pasado estaban desplegando sus miners sin mucho criterio; usaban los scripts maliciosos que servían como downloaders básicos, y el miner era bueno si corría en el sistema de la víctima.
Las tácticas ahora han evolucionado exponencialmente. los scripts maliciosos se están desarrollando para robar información mucho más sensible como credenciales. Ahora también están equipados con otras funciones, como preparar el ambiente para asegurarse de tener los recursos suficientes para minar, siendo lo suficientemente sigilosos para continuar minando el mayor tiempo posible y asegurarse de dejar backdoors en caso de que se necesite una conexión remota con sus víctimas.
Ya que los ataques también ahora están buscando credenciales de Docker, implementar la autentificación de APIs ya no es suficiente. Los administradores de sistemas también deben asegurarse de que la API no está expuesta públicamente y sólo puede ser accedida por aquellos quienes tengan una necesidad absoluta.
Para mantener sus sistemas protegidos, las empresas deben seguir las siguientes mejores prácticas:
- Monitorear y auditar continuamente los dispositivos, especialmente aquellos usados para acceder a la red empresarial
- Seguir el principio del menor privilegio al momento de otorgar permisos
- Estar conscientes del modelo de responsabilidad compartida
- Parchar y actualizar regularmente los sistemas para asegurar que las defensas están al día
- Elegir contraseñas fuertes y nunca usar las que están por defecto
Soluciones de Trend Micro
Trend Micro Hybrid Cloud Security defiende los sistemas nativos de la nube y sus capas. Esta solución todo en uno utiliza el despliegue y descubrimiento automatizados sin fricciones dentro de toolsets existentes. Está potenciado por la plataforma de servicios de seguridad para desarrolladores en la nube, Trend Micro Cloud One™, la cual ofrece protección flexible y automatizada, así como mayor visibilidad para ambientes híbridos y multiube. La plataforma de Trend Micro Cloud One incluye:
- Workload Security: protección en runtime para workloads (virtual, física, nube y containers)
- Container Security: escaneo automatizado de imágenes y registros de containers
- File Storage Security: seguridad para servicios de almacenamiento de archivos y objetos en la nube
- Network Security: seguridad IPS para la capa de la red de la nube
- Application Security: seguridad para funciones serverless, APIs y aplicaciones
- Conformity: seguridad en tiempo real para la infraestructura de la nube – proteja, optimice, cumpla
Indicadores de compromiso
| SHA-256 | Nombre de archivo | Detección de Patrones de Trend Micro |
| 4ad20bcd0f915acba7817e0639fcbf4f713beb8ac35112134808d4e5f753d519 | create_account_dropped.sh | Trojan.SH.MALXMR.UWEKQ
|
| 86800f9e3b563eaeba1d84d431b83405b2118300c0ad2deab39a093d4b9093c5 | kthreadd | Coinminer.Linux.MALXMR.PUWELO |
| 96a64cccb55f7b42711015054ddd6ac45459643aa17c13248c6e344dc787cbfd | setup.sh | Coinminer.SH.MALXMR.UWEJW |
| aad97a08a139e8dff1f02f73479a5b00ecca5b512f627082f9c589fd63479c83 | bioset
|
Trojan.Linux. ZYX.USELVLG20
|
| b3daf217ca7339ad9e738f087135af8f63fd46f435711874ccb4bf8ab310f2e5 | Daemon | N/A
|
Leave a Reply