Aokigahara: el malware que roba las credenciales de tus herramientas de IA
El 23 de octubre de 2026, Check Point Research publicó el informe de un infostealer nuevo que ya aparece en estado natural: Aokigahara, nombr así por el bosque de Aokigahara, al pie del monte Fuji, que la cultura popular japonesa conoce como el bosque encantado. El 27 de octubre, Dark Reading le dedicó una nota a lo que ese malware hace de distinto: no se limita a robar contraseñas del navegador. Va a buscar específicamente los archivos de autenticación y sesión de las herramientas de IA que los desarrolladores ya usan todos los días, y en el mismo barrido se lleva las claves SSH, las credenciales de Git y los archivos de configuración de la nube.
El malware está escrito para Windows, y ahí conviene ser honesto: no es una variante para servidores Linux. Pero el valor que roba sí existe en mis máquinas, y en las tuyas. Lo que me interesa como sysadmin no es si corre sobre Linux, sino que un portátil de desarrollo contaminado le entrega al atacante las llaves que abren tus servidores, las credenciales que gastan tu presupuesto de nube y las conversaciones donde alguien pegó el código que nunca debía pegarse. Eso se verifica y se corrige. Vamos a hacerlo.
TL;DR — Lo que vas a tener al final
- Tiempo de setup: quince minutos con los comandos de auditoría de este post para inventariar tus credenciales de IA y revisar sus permisos.
- Requisitos: una máquina de desarrollo con Claude Code, Codex, Gemini CLI, Cursor o el CLI de GitHub Copilot. No hace falta instalar nada para auditar.
- Resultado: un mapa de qué credenciales de IA, de nube y de Git están en disco y con qué permisos, más un procedimiento de rotación y los indicadores para cazar el malware en los logs.
- Troubleshooting: si un archivo no aparece, la herramienta no está autenticada en esa máquina o usa el almacén del sistema en lugar de un archivo. Revisa la variable de entorno de configuración antes de concluir que estás limpio.
Qué es Aokigahara y en qué se diferencia
El informe de Check Point describe un ejecutable de Windows con una tabla interna de módulos, cada uno responsable de una categoría de archivos. La lista es la de siempre en un infostealer: navegadores Chromium y Firefox, monederos de criptomonedas, clientes VPN, clientes FTP y SFTP, gestores de contraseñas, correo de Outlook y Thunderbird, Discord, Telegram, Steam, Roblox, Minecraft, capturas de pantalla y portapapeles. Todo eso ya lo hemos visto en otras campañas.
Lo nuevo son dos módulos con nombre propio. El primero, aisessions, recorre los archivos de autenticación, sesión y configuración de Claude Code y Claude Desktop, Codex, ChatGPT Desktop, Cursor, Windsurf, Kiro, GitHub Copilot, VS Code, Gemini CLI, el Asistente de IA de JetBrains, Amazon Q y las credenciales de AWS con su caché de SSO. Además consulta el Administrador de credenciales de Windows. El segundo, ide, se ocupa de los editores: VS Code, Cursor, Windsurf y JetBrains, de donde extrae los archivos de credenciales de Git, lo que haya bajo .ssh que parezca una clave privada, los archivos de credenciales y configuración de AWS, Azure y Google Cloud, y el almacenamiento de GitHub Copilot.
El punto que me interesa no es la lista, que es larga, sino la consecuencia. El CTO de Suzu Labs, Denis Calderone, lo resume con una frase que describe el problema real: el asistente de IA de un desarrollador es un keyring. Un archivo de sesión de Claude Code o de Codex no es una preferencia de la herramienta, es un token reutilizable con el mismo poder que tu contraseña. Y el efecto dominó está en la propia documentación del informe: un token válido puede dar acceso a conversaciones privadas y datos de desarrollo, se puede vender para que otro use tu suscripción de pago, o servir para chantajear. Calderone va más allá y recuerda que el historial de conversaciones suele estar lleno de código propietario, así que el mismo token robado vale como activo revendible y como palanca de extorsión.
Un matiz que el propio informe deja explícito y que vale la pena no perder: el análisis confirma qué se recoge, pero no confirma cómo sus operadores monetizan lo robado. La reventa y la extorsión son escenarios que formulan Check Point y otros analistas, no un hecho medido en este malware.
Los archivos que busca, y dónde viven en tu Linux
El informe lista rutas con formato Windows, porque el malware corre sobre Windows. La parte útil para nosotros es la última columna: qué archivo equivalente existe en un equipo Linux, porque el material robado es el mismo aunque el binario no corra ahí.
| Herramienta | Lo que busca el infostealer | Ruta real en Linux |
|---|---|---|
| Claude Code | Credenciales y sesión de la CLI | ~/.claude/.credentials.json con modo 0600 |
| Codex | Token de sesión y configuración | ~/.codex/auth.json (solo si usa almacenamiento en archivo) y ~/.codex/config.toml |
| ChatGPT Desktop | Caché local de la aplicación | No aplica en Linux |
| Cursor | Estado global de la IDE | ~/.config/Cursor/User/globalStorage/state.vscdb |
| Windsurf | Estado global y configuración | ~/.codeium/windsurf/ |
| VS Code | Estado global de la IDE | ~/.config/Code/User/globalStorage/state.vscdb |
| GitHub Copilot (CLI) | Estado de autenticación y proveedores | ~/.copilot/config.json (autenticación), ~/.copilot/providers.json y ~/.copilot/session-state/ |
| Gemini CLI | Variables, configuración y caché de sesión | ~/.gemini/settings.json, ~/.gemini/.env y la caché local de OAuth |
| AWS CLI | Credenciales, configuración y caché de SSO | ~/.aws/credentials, ~/.aws/config, ~/.aws/sso/cache/ |
| Git | Credenciales de Git y claves SSH | ~/.git-credentials y ~/.ssh/ |
Dos detalles de precisión que salvan una regla de detección. El primero: el informe enumera para Claude una ruta con el nombre del archivo de credenciales, mientras que la documentación de Anthropic ubica el archivo real como .credentials.json, con punto delante y permiso 0600. Si armas la regla con el nombre que tú crees y no con el del fabricante, te vas a perder el archivo verdadero. El segundo: GitHub documenta que config.json dentro de ~/.copilot/ guarda el estado de autenticación y el estado interno, mientras que el registro de proveedores y modelos BYOK vive aparte en providers.json; el informe menciona además un hosts.json que no aparece en la documentación vigente de GitHub. Verifica contra el fabricante, no contra el blog.
Y un detalle que cambia el inventario: Google anunció que desde el 18 de junio de 2026 Gemini CLI dejó de atender peticiones en los planes Google AI Pro y Ultra y en el uso gratuito, y esos usuarios pasaron a Antigravity CLI. El informe de Check Point, publicado cuatro meses después, sigue listando a Gemini CLI entre los objetivos, así que la lista de rutas del malware no siempre coincide con el estado actual de la herramienta. Antes de escribir una regla sobre ~/.gemini/, confirma si tu equipo todavía usa Gemini CLI o ya migró.
Qué significa para un servidor Linux
El malware no infecta Linux. Lo que hace es darte, desde tu portátil, las llaves de tus servidores. Y hay cuatro caminos por donde eso ocurre todos los días.
El primero es el más obvio: una clave SSH privada robada en la workstation entra al servidor con los privilegios que tenga esa clave, sin pedir contraseña y sin dejar rastro en el log de autenticación. El segundo son las credenciales de AWS o Azure, que en un entorno de desarrollo suelen tener permisos amplios porque nadie se molestó en acotarlos. El tercero es el código: las credenciales de Git con acceso a repositorios privados son, en la práctica, el código fuente de tu empresa. Y el cuarto es nuevo: la proliferación de asistentes de IA se coló en los servidores. Un contenedor de CI, un runner, un homelab donde alguien instaló Claude Code para no escribir YAML a mano. Ahí la credencial vive en el mismo disco que el código, con la misma política de permisos, y nadie la mira porque nadie la documentó.
El mensaje de Check Point a los equipos de seguridad es directo y lo comparto: la autenticación de las herramientas de IA debe tratarse como secreto de empresa, con la misma protección que se le da a las credenciales de nube y a las claves de desarrollo. Y si sospechas que un endpoint está comprometido, la lista de qué revisar no termina en las contraseñas del navegador: sesiones de IA, claves de API, credenciales de GitHub, claves SSH y tokens de nube.
Auditar tu workstation y tus servidores
Empecemos por el inventario. Esto lista los directorios de configuración de las herramientas de IA que existen en tu home, con su contenido, para saber en qué máquina hay credenciales en disco y en cuál no.
for d in "$HOME/.claude" "$HOME/.codex" "$HOME/.gemini" "$HOME/.aws" "$HOME/.ssh" "$HOME/.copilot" "$HOME/.codeium"; do
if [ -d "$d" ]; then
echo "== $d"
ls -la "$d"
fi
done
Si un directorio no aparece no es que esté limpio: es que esa herramienta no se autenticó en esa máquina, o que usa el almacén de credenciales del sistema en lugar de un archivo. El caso de Claude Code es el que más confunde, porque la documentación dice que el token vive en ~/.claude/.credentials.json con permiso 0600, pero si defines la variable CLAUDE_CONFIG_DIR el archivo se escribe en ese directorio alterno. Con Codex pasa lo mismo: su estado local cuelga de CODEX_HOME, que por omisión es ~/.codex.
El siguiente paso es ver los permisos, porque un archivo de credenciales legible por otros usuarios del sistema es un archivo de credenciales comprometido antes de que llegue el malware:
find "$HOME/.claude" "$HOME/.codex" "$HOME/.gemini" "$HOME/.aws" "$HOME/.ssh" "$HOME/.copilot" -maxdepth 2 -type f 2>/dev/null | xargs -r stat -c '%a %U %n' 2>/dev/null | sort -k1
Lo que buscas es que los archivos de secretos tengan permisos 600 y que los directorios que los contienen tengan 700. Cualquier 644 o 755 es un hallazgo. Para los que estén abiertos de más, el arreglo es inmediato:
chmod 700 "$HOME/.ssh" "$HOME/.aws" "$HOME/.claude" "$HOME/.codex" 2>/dev/null
find "$HOME/.claude" "$HOME/.codex" "$HOME/.aws" -maxdepth 2 -type f 2>/dev/null | xargs -r chmod 600 2>/dev/null
Y para cazar los que el mundo puede leer tal cual:
find "$HOME/.claude" "$HOME/.codex" "$HOME/.gemini" "$HOME/.aws" "$HOME/.ssh" -maxdepth 2 -type f -perm -o+r 2>/dev/null | xargs -r ls -l
El cuarto chequeo es el que más duele cuando se encuentra algo: las claves autorizadas en tu servidor. Si un atacante entra a tu servidor con una clave que no es la tuya, la deja autorizada para volver sin pedirte nada:
if [ -f "$HOME/.ssh/authorized_keys" ]; then
while read -r key || [ -n "$key" ]; do
echo "$key" | ssh-keygen -lf - 2>/dev/null || true
done < "$HOME/.ssh/authorized_keys"
fi
Eso imprime una línea por clave: el tamaño, la huella SHA256:, el comentario y el tipo. El comentario es normalmente el correo o el nombre del equipo donde se generó la clave, y la huella es el dato que comparas contra tu inventario para saber si esa clave es tuya. Si aparece una que no reconoces, no la borres todavía: guárdala, porque es evidencia, y genera una clave nueva.
Revocar y rotar: el paso que casi nadie da
Auditar sirve de poco si después del incidente nadie cambia las credenciales. Las herramientas de IA modernas tienen comandos para cerrar sesión de verdad, no solo para borrar el archivo local:
claude auth status --text
claude auth logout
codex logout
ls -l "$HOME/.codex/auth.json" 2>/dev/null
El claude auth status --text devuelve el estado de autenticación en texto legible y el codex logout elimina las credenciales guardadas, tanto de API key como de sesión de ChatGPT. Ojo con un detalle que un mantenedor de OpenAI explicó en el issue 2557 del repositorio de Codex: cuando haces logout en la CLI, el archivo local auth.json se borra, pero el token no se invalida en el servidor. Si alguien tiene una copia de ese token, por ejemplo un auth.json clonado en otro contenedor, puede seguir usándolo hasta que expire. El issue quedó cerrado como not planned, así que el comportamiento sigue siendo el de hoy: la revocación real se hace desde el panel del proveedor, no solo con el comando local.
Las claves SSH se rotan generando una nueva en local y moviendo esa nueva al servidor, nunca al revés:
ssh-keygen -t ed25519 -C "rotacion-octubre-2026" -f "$HOME/.ssh/id_ed25519_nueva"
ssh-keygen -lf "$HOME/.ssh/id_ed25519_nueva.pub"
La segunda línea imprime la huella de la clave pública: es el valor que vas a tener que comparar con lo que registraste en el servidor, y el que conviene apuntar en tu gestor de contraseñas. El ssh-keygen te va a pedir una passphrase: ponle una, aunque sea larga; una clave privada sin passphrase en el disco es exactamente el tipo de archivo que este malware busca. Cuando la nueva esté funcionando y probada, borras la vieja del servidor y la de tu disco.
Y las credenciales de Git y de nube, que son las que abren el código y el presupuesto:
git config --global --get-all credential.helper
ls -l "$HOME/.git-credentials" "$HOME/.aws/credentials" "$HOME/.aws/sso/cache" 2>/dev/null || true
Si el credential.helper devuelve store, Git está guardando tus credenciales en texto plano en ~/.git-credentials. Es cómodo y es exactamente el archivo que el módulo ide del malware busca. La alternativa es delegar en el gestor de contraseñas del sistema o en un helper que no deje el archivo plano.
Cazar los indicadores en tus logs
El informe publica los indicadores de compromiso: una dirección IP con puerto, siete dominios de mando y control y el User-Agent que usa el malware en sus peticiones. Eso es oro para un sysadmin, porque se busca en los logs del proxy, del cortafuegos o del servidor de registro.
El User-Agent de los analizados más recientes es Microsoft-CryptoAPI/10.0, y el informe advierte que ese valor cambió entre versiones, lo que confirma que el proyecto sigue en desarrollo activo. Los dominios se publican ofuscados con corchetes para no frenar la indexación de los buscadores de malware; los que siguen son los reales:
grep -R -i -E 'Microsoft-CryptoAPI|dfwioeiofwr|dobeqnesmot|hjazfioe|kkeyyou|neihite|somelitersofblood' /var/log 2>/dev/null | head -20
Y para ver si esta máquina está hablando con el servidor de mando y control:
ss -tnp | grep -E '2[.]26[.]252[.]48|:8080' || true
Si esa búsqueda devuelve algo, ya no es una hipótesis. Aísla la máquina, captura el proceso que mantiene la conexión y empieza la rotación completa de todo lo que aparece en la tabla de arriba.
Como barrera adicional, para bloquear los dominios en la red interna sin depender del cortafuegos:
for d in dfwioeiofwr.info gate.dfwioeiofwr.info dobeqnesmot.cc hjazfioe.surf kkeyyou.cc neihite.cc somelitersofblood.pw; do
echo "0.0.0.0 $d"
done
Esa lista es para revisar el resultado antes de aplicarlo, no un comando de escritura. Cuando confirmes los dominios contra el informe vigente, los pasas al archivo de bloqueo de tu resolutor o al cortafuegos. Es una barrera de contención, no un sustituto de la rotación: el atacante cambia de dominio en la siguiente versión, y el informe es claro en que el desarrollo del malware sigue activo.
Cómo funciona la exfiltración
Si te interesa la ingeniería, el protocolo de subida merece un vistazo. El malware abre sesión contra tres rutas del servidor: /gate/handshake para registrar la sesión enviando una clave pública X25519, /gate/chunk para subir cada bloque de datos robados, y /gate/complete para cerrar. Cada bloque va en un ZIP cifrado con AES-256-GCM, con un nonce de 12 bytes al inicio y una etiqueta de autenticación de 16 bytes al final. La clave de cifrado se deriva de un secreto compartido X25519 aplicando SHA-256 con la cadena fija aokigahara.
La configuración vive en una sección .stgcfg del ejecutable, con un valor mágico STGC y un vector de inicialización de 16 bytes, y la clave AES-256-CBC se deriva de una semilla con una función propia. Cada módulo se activa según una máscara de bits en esa configuración, y el informe advierte que todos los módulos quedan embebidos aunque estén desactivados: un análisis estático del binario muestra capacidades que una ejecución concreta no usa. También incluye un chequeo de idioma que aborta la ejecución si el teclado o el idioma de la interfaz del sistema coincide con alguno de los identificadores de una máscara que excluye ruso, ucraniano y bielorruso, entre otros, una señal de que el malware evita correr en esas regiones. Para los defensores, el informe publica además una regla de YARA con cadenas reconocibles como X-Chunk-Index, AISessions/ y un pipe con prefijo akg_, además de las cadenas aokigahara y kamidere: el informe advierte que una versión anterior del malware pudo ser conocida con ese segundo nombre o como Stygian.
Mi veredicto como sysadmin
Vale la pena, y por una razón que no es alarmismo: el vector es real, silencioso y rentable. Robar una sesión de IA no da acceso a un correo de trabajo, da acceso al contexto: el código, los prompts, los documentos que alguien pegó en un chat porque la herramienta se lo pidió. Es un concentrador de secretos que antes no existía en tu inventario de riesgo y, por lo tanto, nadie lo está defendiendo.
Pero que nadie confunda prioridad con alarma. Aokigahara es Windows, y la mayoría de los servidores Linux que administras no tienen un Claude Code instalado. El riesgo real es de cadena: workstation contaminada, servidor comprometido después por SSH, o credencial de nube en un contenedor que nadie revisó. En ese orden de probabilidad es donde hay que poner el esfuerzo.
Mi plan, en orden: primero el inventario y los permisos, porque es gratis y se hace en quince minutos; después, verificar que ninguna clave autorizada en tus servidores sea desconocida; luego, rotar lo que de verdad se usa; y por último, elegir un mecanismo para que las credenciales de IA no vivan como archivos planos de por vida. Eso último es el trabajo de fondo: credenciales de corta duración, identidades administradas donde se pueda, y una política explícita de qué se puede pegar en un chat de IA y qué no. Ninguna herramienta te salva de pegar el código de tu empresa en el chat equivocado; lo que esto hace es quitarle al atacante la capacidad de recolectar en masa cuando entra por otro lado.
Preguntas frecuentes
¿Aokigahara infecta servidores Linux o solo máquinas con Windows?
El malware está escrito para Windows: el informe describe rutas, el portapapeles y el Administrador de credenciales de ese sistema, y no se ha publicado una variante para Linux. Pero lo que roba, es decir claves SSH, credenciales de Git y tokens de nube, existe igual en tus máquinas Linux. El servidor no se infecta: se entra con una llave robada en el portátil.
¿Dónde queda la credencial de Claude Code en un equipo Linux?
En ~/.claude/.credentials.json con permisos 0600, según la documentación de Anthropic. Pero si defines CLAUDE_CONFIG_DIR, el archivo se escribe en ese directorio alterno, y si usas el almacén del sistema en vez del archivo, en disco no hay nada que revisar. Para Codex el equivalente es ~/.codex/auth.json, gobernado por CODEX_HOME.
¿Cómo sé si una máquina ya fue comprometida por este malware?
Por los indicadores publicados: el User-Agent Microsoft-CryptoAPI/10.0, la IP 2.26.252.48 en el puerto 8080 y los siete dominios de mando y control. Búscalos en los logs del proxy, del cortafuegos y del servidor de registro, y revisa las claves autorizadas en los servidores por si quedó una puerta trasera. Si algo coincide, aísla la máquina y rota todo.
¿Basta con cambiar la contraseña de la suscripción de IA?
No. La suscripción se paga con un token de sesión, y lo que se roba es ese token y los archivos de credenciales, no una contraseña que puedas cambiar. Toca cerrar sesión con claude auth logout y codex logout, revocar la sesión desde el panel del proveedor, y rotar además claves SSH, credenciales de Git y tokens de nube, que comparten el mismo barrido.
¿Puedo seguir usando asistentes de IA en mi homelab o mi servidor?
Sí, con tres condiciones: que las credenciales vivan con permisos restrictivos, que no se sincronicen entre equipos por herramientas de dotfiles sin filtrar, y que el directorio de configuración se aísle por proyecto con CLAUDE_CONFIG_DIR o CODEX_HOME. En integración continua, lo más limpio es usar tokens de corta duración inyectados por el runner en vez de un archivo persistente.
