El actor de amenazas norcoreano conocido como UNC4899 Se sospecha que está detrás de una sofisticada campaña de compromiso en la nube dirigida a una organización de criptomonedas en 2025 para robar millones de dólares en criptomonedas.
La actividad se ha atribuido con moderada confianza al adversario patrocinado por el estado, al que también se le rastrea bajo los criptoónimos Jade Sleet, PUKCHONG, Slow Pisces y TraderTraitor.
«Este incidente se destaca por su combinación de ingeniería social, explotación de mecanismos de transferencia de datos entre pares (P2P) de dispositivos personales a corporativos, flujos de trabajo y eventual giro a la nube para emplear técnicas de vida fuera de la nube (LOTC)», señaló el gigante tecnológico en su informe Cloud Threat Horizons del primer semestre de 2026, compartido con The Hacker News.
Al obtener acceso al entorno de la nube, se dice que los atacantes abusaron de los flujos de trabajo legítimos de DevOps para recopilar credenciales, romper los límites de los contenedores y alterar las bases de datos de Cloud SQL para facilitar el robo de criptomonedas.
La cadena de ataque, dijo Google Cloud, representa una progresión de lo que comenzó con el compromiso del dispositivo personal de un desarrollador en su estación de trabajo corporativa, antes de saltar a la nube para realizar modificaciones no autorizadas a la lógica financiera.
Todo comenzó cuando los actores de amenazas utilizaron estrategias de ingeniería social para engañar al desarrollador para que descargara un archivo como parte de una supuesta colaboración en un proyecto de código abierto. Luego, el desarrollador transfirió el mismo archivo al dispositivo de su empresa a través de AirDrop.
«Utilizando su entorno de desarrollo integrado (IDE) asistido por IA, la víctima interactuó con el contenido del archivo y finalmente ejecutó el código Python malicioso incrustado, que generó y ejecutó un binario que se hacía pasar por la herramienta de línea de comandos de Kubernetes», dijo Google.
Luego, el binario se puso en contacto con un dominio controlado por el atacante y actuó como una puerta trasera para la máquina corporativa de la víctima, brindando a los atacantes una forma de pasar al entorno de Google Cloud probablemente usando sesiones autenticadas y credenciales disponibles. A este paso le siguió una fase inicial de reconocimiento destinada a recopilar información sobre diversos servicios y proyectos.
El ataque pasó a la siguiente fase con el descubrimiento de un host bastión, en el que el adversario modificó su atributo de política de autenticación multifactor (MFA) para acceder a él y realizar reconocimientos adicionales, incluida la navegación a pods específicos dentro del entorno de Kubernetes.
Posteriormente, UNC4899 adoptó un enfoque de vivir fuera de la nube (LotC) para configurar mecanismos de persistencia alterando las configuraciones de implementación de Kubernetes para ejecutar un comando bash automáticamente cuando se crean nuevos pods. El comando, por su parte, descargaba una puerta trasera.
Algunos de los otros pasos llevados a cabo por el actor de amenazas se enumeran a continuación:
- Los recursos de Kubernetes vinculados a la solución de plataforma CI/CD de la víctima se modificaron para inyectar comandos que mostraban los tokens de la cuenta de servicio en los registros.
- El atacante obtuvo un token para una cuenta de servicio CI/CD con altos privilegios, lo que le permitió escalar sus privilegios y realizar movimientos laterales, apuntando específicamente a un pod que manejaba políticas de red y equilibrio de carga.
- El token de la cuenta de servicio robado se utilizó para autenticarse en el pod de infraestructura confidencial que se ejecuta en modo privilegiado, escapar del contenedor e implementar una puerta trasera para acceso persistente.
- El actor de amenazas llevó a cabo otra ronda de reconocimiento antes de centrar su atención en una carga de trabajo responsable de administrar la información del cliente, como las identidades de los usuarios, la seguridad de la cuenta y la información de la billetera de criptomonedas.
- El atacante lo usó para extraer credenciales de bases de datos estáticas que estaban almacenadas de forma insegura en las variables de entorno del pod.
- Luego se abusó de las credenciales para acceder a la base de datos de producción a través de Cloud SQL Auth Proxy y ejecutar comandos SQL para realizar modificaciones en la cuenta de usuario. Esto incluyó restablecimientos de contraseñas y actualizaciones de semillas de MFA para varias cuentas de alto valor.
- El ataque culminó con el uso de cuentas comprometidas para retirar con éxito varios millones de dólares en activos digitales.
El incidente «destaca los riesgos críticos planteados por los métodos de transferencia de datos P2P de persona a empresa y otros puentes de datos, modos de contenedores privilegiados y el manejo no seguro de secretos en un entorno de nube», dijo Google. «Las organizaciones deben adoptar una estrategia de defensa en profundidad que valide rigurosamente la identidad, restrinja la transferencia de datos en los puntos finales y aplique un aislamiento estricto dentro de los entornos de ejecución de la nube para limitar el radio de explosión de un evento de intrusión».
Para contrarrestar la amenaza, se recomienda a las organizaciones implementar acceso contextual y MFA resistente al phishing, asegurarse de que solo se implementen imágenes confiables, aislar los nodos comprometidos para que no establezcan conectividad con hosts externos, monitorear procesos de contenedores inesperados, adoptar una gestión sólida de secretos, aplicar políticas para deshabilitar o restringir el intercambio de archivos entre pares mediante AirDrop o Bluetooth y montar medios externos no administrados en dispositivos corporativos.