De un AirDrop a la nube: el ataque living-off-the-cloud que vació millones en cripto

Un sofisticado ataque dirigido a una empresa del ecosistema de criptomonedas ha vuelto a poner de relieve cómo una intrusión que empieza en el dispositivo personal de un desarrollador puede terminar vaciando carteras por millones de dólares en un entorno cloud. Según el informe semestral de amenazas en la nube de Google Cloud, atribuido con nivel moderado de confianza a un grupo vinculado a Corea del Norte (rastreados bajo siglas como UNC4899 entre otros), la campaña combinó ingeniería social, abuso de mecanismos de transferencia personal-a-corporativo y técnicas de pivotaje propias del llamado living‑off‑the‑cloud para escalar privilegios y manipular la lógica financiera en producción (H1 2026 Cloud Threat Horizons Report).

El punto de entrada fue sencillo, pero efectivo: los atacantes se hicieron pasar por colaboradores de un proyecto de código abierto y lograron que el desarrollador descargara un archivo comprimido aparentemente legítimo. Ese mismo archivo pasó del teléfono personal al equipo corporativo mediante AirDrop, y fue abierto dentro de un entorno de desarrollo asistido por IA. El código Python malicioso incrustado se ejecutó y desplegó posteriormente un binario que imitaba la herramienta de línea de comandos de Kubernetes, proporcionando una puerta trasera silenciosa hacia la máquina corporativa.

Desde esa máquina comprometida los atacantes recolectaron sesiones y credenciales disponibles para moverse hacia el entorno cloud. En una fase inicial realizaron reconocimiento de los proyectos y servicios infranqueados hasta localizar una puerta de entrada más crítica: un bastion host que, tras modificar atributos relacionados con la autenticación multifactor, les permitió profundizar en pods concretos del clúster Kubernetes (qué es un bastion host).

La forma en que los operadores mantuvieron presencia y la facilidad con la que pivotaron dentro del entorno ilustra por qué los defensores hablan de vivir de la nube: modificaron configuraciones de despliegue para que, cada vez que se creara un pod, se ejecutara automáticamente un comando bash capaz de descargar y ejecutar un backdoor. A la vez, introdujeron cambios en recursos vinculados a la plataforma CI/CD para registrar tokens de cuentas de servicio en los logs, lo que les permitió apropiarse de un token de alto privilegio y usarlo para moverse lateralmente hacia pods con permisos elevados y modos privilegiados de ejecución.

Con ese acceso privilegiado los atacantes consiguieron escapar del contenedor y desplegar persistencia en infraestructura sensible. Más adelante enfocaron sus esfuerzos en una carga de trabajo que almacenaba información de clientes: identificadores, configuraciones de seguridad y datos asociados a las carteras. Allí extrajeron credenciales estáticas que se encontraban en variables de entorno y las usaron para conectarse a la base de datos de producción mediante el proxy de Cloud SQL, donde efectuaron cambios en cuentas (restablecimiento de contraseñas y actualización de semillas MFA) para hacerse finalmente con el control de cuentas de alto valor y retirar varios millones en activos digitales.

El incidente contiene varias lecciones que no son nuevas pero sí persistentes: las transferencias personales‑a‑corporativas (AirDrop, Bluetooth, medios extraíbles no gestionados) siguen siendo vectores de entrada peligrosos; los contenedores ejecutados en modo privilegiado amplifican el daño potencial; y el manejo de secretos en texto claro o en variables de entorno sigue facilitando la escalada y la exfiltración cuando cae en manos equivocadas. Por eso los autores del informe recomiendan una aproximación en profundidad que combine controles de identidad, restricciones en puentes de datos y aislamiento estricto en los runtimes cloud.

En la práctica, eso implica validar continuamente la identidad y usar factores resistentes al phishing, restringir o deshabilitar el intercambio P2P en dispositivos corporativos, exigir imágenes de contenedor de confianza y políticas que impidan que nodos comprometidos establezcan comunicaciones salientes no autorizadas. También obliga a vigilar procesos inusuales dentro de contenedores y a migrar credenciales y secretos fuera de variables de entorno hacia soluciones de gestión de secretos robustas y auditables. Para comprender mejor cómo funciona el acceso a bases de datos desde entornos gestionados puede consultarse la documentación oficial del Cloud SQL Auth Proxy.

La comunidad de seguridad en la nube dispone además de material de referencia para endurecer plataformas y prácticas: la documentación oficial de Kubernetes sobre seguridad y políticas de pod es un buen punto de partida (Kubernetes: conceptos de seguridad), y los marcos de amenazas como el catálogo de MITRE ayudan a mapear técnicas observadas con mitigaciones conocidas (MITRE ATT&CK for Cloud).

También resulta útil revisar recomendaciones oficiales sobre el uso seguro de funciones de transferencia entre dispositivos. Apple, por ejemplo, documenta cómo funciona AirDrop y qué controles existen para limitar su uso, algo relevante si se quiere reducir el riesgo de que un archivo malicioso cruce la línea entre lo personal y lo laboral (soporte Apple: AirDrop).

Este episodio es una invitación a repensar la arquitectura de confianza en los equipos de desarrollo y operaciones: la comodidad de usar asistentes de código y transferir artefactos entre dispositivos no debe borrar la necesidad de controles básicos. Una combinación de políticas de acceso contextuales, MFA robusta, gestión adecuada de secretos y segmentación de runtime puede reducir drásticamente la superficie de ataque, pero requiere disciplina organizativa y visibilidad continua sobre lo que ocurre dentro de clústeres y pipelines.

Que actores con motivaciones estatales recurran a técnicas tan integradas —desde la ingeniería social hasta la manipulación de despliegues en Kubernetes— subraya que los escenarios de riesgo actuales son híbridos y encadenados: un pequeño descuido en el extremo del desarrollador puede convertirse, si se explotan las debilidades del entorno cloud, en un robo multimillonario. La prevención pasa por cerrar esas cadenas en todos sus eslabones y por invertir en controles que dificulten el movimiento lateral y la persistencia una vez dentro.