El malware de tipo infostealer está permitiendo que los criminales accedan a entornos corporativos en la nube de forma más discreta. En lugar de intentar vulnerar el perímetro de seguridad, infectan los dispositivos de empleados o desarrolladores para robar credenciales, claves API y sesiones activas que ya cuentan con la confianza de la organización. Estas infecciones iniciales suelen ocurrir a través de phishing, descargas engañosas o paquetes maliciosos.

El malware de tipo infostealer está ofreciendo a los criminales una ruta más silenciosa para entrar en los entornos de nube corporativos. En lugar de forzar su entrada a través de un perímetro de nube reforzado, infectan el dispositivo de un desarrollador o empleado y roban las credenciales, las claves API y las sesiones activas que ya cuentan con la confianza de la organización.

La infección inicial puede llegar a través de phishing, descargas engañosas o una dependencia de software envenenada. Una vez que se ejecuta, un stealer recopila rápidamente datos del navegador y secretos locales del desarrollador; luego, los operadores pueden vender ese acceso a otros criminales.

Estas campañas ponen cada vez más en riesgo los entornos de nube, código e IA. Su análisis de sistemas infectados reveló que Lumma C2, RedLine y Vidar representaron el 85,7 por ciento de los incidentes detectados.

Wiz.io afirmó en un informe que los secretos de AWS y Google Cloud representaron el 46 por ciento y el 13 por ciento de los secretos comprometidos, respectivamente.

Un token válido puede abrir consolas de nube, repositorios de código, tuberías de compilación (build pipelines) y servicios de IA, exponiendo datos o incrementando los costes. Este patrón refleja fielmente cómo los registros de infostealers impulsan las brechas de seguridad, donde los criminales compran el acceso en lugar de explotar fallos.

No necesitan irrumpir en la nube

A menudo, los atacantes no necesitan vencer la autenticación de múltiples factores. Se crea un token de sesión de navegador después de que un usuario legítimo inicia sesión. Si el malware roba ese token y un atacante lo carga en otro navegador, es posible que el servicio trate al atacante como el usuario autenticado.

Las credenciales de larga duración extienden esa oportunidad. Las claves de acceso de AWS guardadas en los archivos de configuración del desarrollador pueden proporcionar acceso programático directo, mientras que los tokens de AWS SSO almacenados en caché pueden permitir que un atacante obtenga credenciales temporales nuevas.

En Azure, las cachés de identidad y la CLI local pueden revelar tokens de acceso o de actualización, información del inquilino (tenant) y cuentas. Las máquinas de desarrolladores de Google Cloud también son atractivas porque las credenciales de línea de comandos y las rutas de claves de cuentas de servicio pueden proporcionar un acceso duradero a proyectos de producción valiosos.

Las plataformas de control de versiones añaden otra vía: un token de repositorio, una clave SSH o una sesión robada pueden exponer código privado, variables de CI/CD y configuraciones de despliegue.

Los tokens de GitHub representaron aproximadamente el 10 por ciento de los secretos robados, mientras que los secretos de plataformas de IA составили el 5 por ciento. Las credenciales de IA se han convertido cada vez más en parte del mismo botín: las claves robadas pueden consumir servicios a expensas de la víctima, mientras que las sesiones robadas pueden exponer historiales de chat internos.

El riesgo se asemeja a ataques recientes a infraestructuras de IA, donde los sistemas expuestos crearon una ruta hacia claves y recursos conectados. Los dispositivos de desarrolladores personales o gestionados superficialmente pueden contener acceso empresarial privilegiado sin contar con las mismas protecciones corporativas.

Los atacantes han abusado de herramientas legítimas de Windows y archivos relacionados con juegos troyanizados, mientras que los stealers de cadena de suministro ahora apuntan a servidores de compilación y procesos de CI/CD sin depender del phishing.

Desde la infección hasta la recuperación

Los operadores de "malware como servicio" distribuyen los stealers, luego los corredores de acceso inicial clasifican los registros robados, validan las cuentas valiosas y las revenden. Por lo tanto, una sola descarga descuidada puede convertirse en un incidente de nube después de la infección, como han demostrado las campañas de MacSync centradas en desarrolladores.

Tú y tu organización deberíais tratar una infección confirmada por infostealer como un incidente de identidad, no simplemente como una tarea de limpieza de malware. Aísla el dispositivo afectado, investiga las cuentas utilizadas en él, revoca las sesiones activas y rota las contraseñas, claves API, claves SSH, credenciales de nube y tokens de repositorio desde un dispositivo limpio.

Tus equipos deberían revisar los registros de nube, identidad, control de versiones y CI/CD en busca de sesiones desconocidas, nuevas claves de acceso, actividad de tokens inusual, cambios en los roles y repositorios inesperados.

Reconstruir los endpoints afectados desde fuentes limpias es más seguro que asumir que la eliminación del malware también elimina el acceso robado. La prevención debería reducir el valor de los datos disponibles en los endpoints.

Usa credenciales de corta duración e identidad de carga de trabajo siempre que sea posible, protege los secretos con el llavero del sistema operativo o una bóveda gestionada, mantén los dispositivos de desarrollador gestionados y limita estrictamente los permisos.

Las lecciones de la exposición de la cadena de suministro de LiteLLM también respaldan el anclaje (pinning) de dependencias y la revisión del comportamiento en el momento de la compilación. Una autenticación de múltiples factores fuerte sigue siendo importante, pero no es suficiente cuando un atacante puede reproducir una sesión válida.

Deberías exigir controles de acceso basados en el dispositivo para servicios sensibles, monitorear las credenciales expuestas y revocar las sesiones rápidamente cuando cambien las señales de riesgo. Proteger la nube significa proteger cada endpoint que guarda sus claves.