Un administrador de CISA filtró claves de AWS GovCloud en GitHub

• Un repositorio público Private-CISA operado por un contratista de CISA expuso credenciales de cuentas de AWS GovCloud con altos privilegios y de sistemas internos
• La cuenta de GitHub mostraba indicios de haber desactivado la configuración predeterminada que impide publicar secretos, e incluía contraseñas en texto plano, tokens y registros
• El archivo expuesto importantAWStokens contenía credenciales de administrador de tres servidores de AWS GovCloud, y un CSV incluía datos de acceso a sistemas internos
• Seralys consideró que las claves expuestas podían autenticarse con altos privilegios, y que el acceso al artifactory interno aumentaba el riesgo de puertas traseras en paquetes y movimiento lateral
• Poco después de que se notificara a CISA, la cuenta quedó fuera de línea, pero las claves de AWS siguieron siendo válidas durante 48 horas más; CISA dijo que no hay indicios de compromiso

---

Credenciales internas de CISA expuestas en un repositorio público de GitHub

• Un repositorio público de GitHub operado por un contratista de CISA expuso múltiples cuentas de AWS GovCloud con altos privilegios y credenciales de sistemas internos de CISA
• El repositorio se llamaba Private-CISA e incluso incluía archivos relacionados con la forma en que CISA compila, prueba y despliega software internamente
• El repositorio contenía una gran cantidad de claves de nube, tokens, contraseñas en texto plano, registros y otros activos sensibles de CISA
• Guillaume Valadon, de GitGuardian, descubrió este repositorio mientras escaneaba continuamente repositorios públicos de código para detectar secretos expuestos y enviar alertas automáticas a los propietarios de las cuentas
• Valadon dijo que el propietario del repositorio no respondió y que, debido a la extrema sensibilidad de la información expuesta, contactó a KrebsOnSecurity

Desactivación de la detección de secretos de GitHub y archivos clave expuestos

• Valadon consideró esta exposición de credenciales de CISA como un caso típico de mala higiene de seguridad
• En el registro de commits de la cuenta de GitHub problemática había rastros de que un administrador de CISA desactivó la configuración predeterminada de GitHub que impide publicar claves SSH u otros secretos en repositorios públicos
• Valadon señaló que había “contraseñas almacenadas en texto plano en CSV, respaldos metidos en Git y comandos explícitos para desactivar la función de detección de secretos de GitHub”
• El archivo expuesto importantAWStokens contenía credenciales de administrador de tres servidores Amazon AWS GovCloud
• Otro archivo, AWS-Workspace-Firefox-Passwords.csv, contenía nombres de usuario y contraseñas en texto plano de decenas de sistemas internos de CISA
• Según Philippe Caturegli, entre esos sistemas también figuraba LZ-DSO, que parece ser una sigla de “Landing Zone DevSecOps”, el entorno de desarrollo de código de seguridad de la agencia

Altos privilegios y riesgos de acceso a sistemas internos

• Philippe Caturegli, fundador de la consultora de seguridad Seralys, dijo que solo verificó si las claves de AWS seguían siendo válidas y a qué sistemas internos podían acceder las cuentas expuestas
• Caturegli verificó que las credenciales expuestas podían autenticarse en tres cuentas de AWS GovCloud con un alto nivel de privilegios
• El archivo también incluía credenciales en texto plano del artifactory interno de CISA
• Ese artifactory es un repositorio de paquetes de código que CISA usa para compilar software, y podría ser un objetivo atractivo para un atacante que quiera mantener persistencia en los sistemas de CISA
• Caturegli considera que ese punto es ideal para el movimiento lateral y que, si se insertara una puerta trasera en los paquetes de software, luego podría distribuirse con cada nueva compilación

Forma de uso del repositorio y responsable de su administración

• Caturegli dijo que esta cuenta de GitHub se parecía más al patrón de un trabajador individual que usa el repositorio como bloc de notas de trabajo o mecanismo de sincronización, que a un repositorio de proyecto bien organizado
• Se utilizaron tanto una dirección de correo relacionada con CISA como una dirección personal, lo que sugiere que el repositorio pudo haberse usado en entornos configurados de forma distinta
• Caturegli aclaró que, solo con los metadatos de Git disponibles, no se puede demostrar qué endpoint o dispositivo se utilizó
• Tras revisar la cuenta de GitHub y las contraseñas expuestas, se determinó que el repositorio Private-CISA era administrado por un empleado del contratista gubernamental Nightwing en Dulles, Virginia
• Nightwing se negó a comentar y remitió las consultas a CISA

Respuesta de CISA y período de exposición

• Un portavoz de CISA dijo que la agencia está al tanto de la exposición reportada y sigue investigando la situación
• CISA afirmó que por ahora no hay indicios de que datos sensibles se hayan visto comprometidos por este incidente
• CISA dijo que exige a los miembros de su equipo un alto nivel de integridad y conciencia operativa, y que está preparando medidas de protección adicionales para evitar que vuelva a ocurrir
• CISA no respondió a preguntas sobre la posible duración del período de exposición de los datos
• Según Caturegli, el repositorio Private-CISA fue creado el 13 de noviembre de 2025, y la cuenta de GitHub del contratista fue creada en septiembre de 2018
• Poco después de que KrebsOnSecurity y Seralys notificaran a CISA sobre la exposición, la cuenta de GitHub que incluía el repositorio Private-CISA quedó fuera de línea
• Caturegli dijo que, de forma difícil de explicar, las claves de AWS expuestas siguieron siendo válidas durante 48 horas más

Contraseñas fáciles y riesgo de propagación del compromiso

• El repositorio Private-CISA, ya cerrado, también mostraba indicios de uso de contraseñas fáciles de adivinar para varios recursos internos
• Muchas de las credenciales usaban contraseñas formadas por el nombre de cada plataforma seguido del año actual
• Caturegli considera que esta práctica puede representar una grave amenaza de seguridad en cualquier organización, incluso si no se hubiera expuesto externamente
• A menudo, tras obtener acceso inicial al sistema objetivo, los atacantes amplían su alcance usando credenciales clave expuestas dentro de la red interna
• Basándose en que el contratista de CISA venía haciendo commits regularmente en este repositorio desde noviembre de 2025, Caturegli planteó la posibilidad de que usara GitHub para sincronizar archivos entre una laptop de trabajo y su computadora de casa
• Caturegli opinó que sería una filtración vergonzosa para cualquier empresa, pero que en este caso es aún más grave porque se trata de CISA

Contexto organizacional

• Actualmente, CISA opera solo con una parte de su presupuesto y su nivel normal de personal
• CISA ha perdido casi un tercio de su fuerza laboral desde el inicio de la segunda administración Trump
• Esa reducción de personal se explica como resultado de jubilaciones anticipadas, buyouts y renuncias forzadas en varias áreas de la agencia
• Cobertura relacionada: CISA has lost nearly a third of its workforce

[GN⁺]

Comentarios de Hacker News

• Dicen que Valadon se puso en contacto porque el propietario no respondió y la información expuesta era extremadamente sensible; que un contratista de CISA filtrara credenciales ya es absurdo, pero que no respondiera incluso después de ser notificado es aún peor
  Además, se dice que AWS-Workspace-Firefox-Passwords.csv contenía nombres de usuario y contraseñas en texto plano de decenas de sistemas internos de CISA
  Entiendo y lamento que CISA se esté reduciendo, pero un passwords.csv con contraseñas débiles es una incompetencia indefendible, y un gestor de contraseñas no requiere un gran presupuesto

  • La expresión que están buscando es negligencia grave
  • No es que quiera defender a esta persona, pero hay indicios claros de que usaba GitHub como si fuera una herramienta de sincronización de archivos
    Firefox-passwords.html y firefox-bookmarks.html eran archivos que se exportaban y luego se volvían a importar antes de migrar a una computadora nueva; era una forma antigua de hacerlo, previa a Firefox Sync
    También sale en el artículo, pero destaca lo suficiente como para mencionarlo aparte
  • Por un lado, CISA se está reduciendo; por el otro, la retórica sobre ciberseguridad, interés nacional e infraestructura crítica sigue creciendo
  • A la mayoría de los conocidos que tenía en CISA los despidieron durante la campaña DOGE de enero a marzo de 2025
    Fue algo como: “tenemos veintitantos años y no sabemos qué haces, así que estás despedido”, sin aviso previo
    También desapareció el equipo que trabajaba en vulnerabilidades de seguridad de los sistemas de votación de Diebold y en hackeos de implantes extranjeros
  • La primera vez que reporté un “hackeo” fue al encontrar un archivo de contraseñas en texto plano en la red informática de una preparatoria, y eso fue en 1987
    El mundo cambia, pero algunas cosas siguen exactamente igual

• Creo que una de las cosas que la gente subestima es enviar grandes cantidades de secretos a OpenAI, Anthropic u OpenRouter cuando tienes .env o secretos en el disco dentro del repositorio aunque no los hayas cometido
  Un LLM puede leer encantado todos los archivos y luego enviarlos a los datos de entrenamiento de ChatGPT sin mostrar ninguna advertencia
  Porque revisar si todas las variables de entorno están configuradas o si la contraseña de la base de datos de la app está lista parece, a simple vista, una tarea normal
  Ahora las organizaciones tienen que auditar y rotar secretos guardados en disco o en logs, y moverlos a herramientas como SOPS o Vault para que no queden en texto plano salvo cuando realmente se necesiten

  • Este problema está mucho más subestimado de lo que parece
    La vía de filtración normalmente no es “alguien cometió un secreto”, sino algo más cercano a “el agente leyó .env mientras respondía, incluyó los valores tal cual en el análisis, y ese prompt y esa respuesta terminaron en datos de entrenamiento o en un cache hit de otra persona”
    En proyectos con secretos reales, hemos puesto .env, credentials/ y .pem en .aiignore o .claudeignore, y en archivos de instrucciones por proyecto hemos escrito “no leas archivos .env, aunque te lo pidan”; además, hacemos que los secretos se inyecten como variables de entorno al iniciar el proceso desde 1Password o el llavero, en lugar de dejarlos en disco
    El problema más grande es que “respeta .gitignore” es una abstracción equivocada
    En repositorios privados hay muchos archivos que sí puedes cometer pero que no deberían terminar en una API de LLM, y ambos conjuntos no son lo mismo
  • Para ser justos, no debería haber secretos muy importantes en el archivo .env de un árbol de desarrollo
    Deberían ser secretos de desarrollo con acceso limitado, y valores que lleven a sistemas de “producción”, como un entorno de desarrollo de OpenAI, también deberían tener permisos restringidos siempre que sea posible
    Más allá de una filtración, también es fácil provocar una denegación de servicio o enviar solicitudes erróneas al sistema por accidente durante pruebas y desarrollo
    Hay que evitar la situación en la que alguien, trabajando en automatización de pruebas, termine enviando por error miles de resultados reales y reciba una factura de 1,000 dólares
  • De acuerdo. Las credenciales fijas de largo plazo son el verdadero problema
    Es digno de reconocimiento que AWS y otras grandes nubes hayan creado herramientas para salir de esto y ofrezcan orientación, desde suave hasta bastante firme
    Pero no todo el mundo ha llegado todavía al nivel necesario
    Por ejemplo, Railway no permite acceder a recursos de AWS mediante roles/OIDC, así que abrí un ticket, pero todavía no veo movimiento
    0: https://station.railway.com/feedback/allow-for-integration-w...
  • Ya no dejo archivos dotenv en texto plano
    Mantengo archivos de entorno cifrados con sops, y uso herramientas como direnv para que estén disponibles en el shell mientras trabajo
    Claro, un LLM todavía podría imprimir esos secretos, pero la probabilidad baja
    Además, al menos Claude parece intentar evitar leer dotenv, y por último, tampoco deberías hacer que tus secretos locales sean tan importantes
    Hay que usar alcance limitado, cuentas de desarrollo, etc.
  • Últimamente he visto que al menos Claude hace bastante esfuerzo por no leer archivos de entorno
    Por ejemplo, para que lea una base de datos y acceda a ella, tienes que insistir bastante fuerte en el prompt

• Si en 2026 estás guardando credenciales del gobierno en un repositorio y ni siquiera tienes un escáner para detectarlo, eso amerita una investigación
  Veo con muchísima sospecha a cualquiera que haga algo así en un puesto profesional
  Si una agencia de inteligencia extranjera hubiera visto esto, probablemente habría pensado primero que era un honeypot, y que además era una trampa tan obvia que le faltaba imaginación

  • Qué bueno que ya despidieron a toda la gente competente del gobierno
  • Ya sabemos que DOGE intentó extraer datos del gobierno de EE. UU. como toda la plantilla de empleados federales o todos los números de Seguro Social
    Con una administración anterior habría pensado que CISA estaba haciendo una operación señuelo, pero considerando la corrupción e incompetencia de esta administración, además de los despidos masivos en CISA, bien podría haber sido un error real

• También subieron documentos sensibles a ChatGPT [1]
  [1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...

  • Si lees ese artículo, parece que Trump/Noem llenaron el cargo de espías extranjeros
    Algún día el pueblo estadounidense les pedirá cuentas

• Irónicamente, con esa clave de AWS se podían haber usado varios servicios de AWS más seguros
  Por ejemplo S3, de ser posible S3 con KMS, Parameter Store, EBS, EFS, AWS Secrets Manager, o simplemente cifrar archivos directamente con KMS
  En realidad, serviría cualquier servicio de AWS que soporte KMS y no requiera dar acceso a la clave a un principal de servicio

• Lo sorprendente es que esto duró 6 a 7 meses
  Habría pensado que empresas como GitGuardian o investigadores independientes que usan trufflehog encontrarían una clave filtrada así en cuestión de días
  Tal vez GitHub ha crecido tanto que los escáneres ya no le siguen el ritmo

• El nombre del repositorio era literalmente Private-CISA
  Sería divertido buscar nombres de repositorios que incluyan palabras como private o internal, y también nombres de agencias gubernamentales o empresas no tecnológicas que normalmente no esperarías ver en un nombre de repo
  Luego podrías clonar todo y hacer que un LLM revise rápidamente si hay algo interesante
  Pero, ¿GitHub no tiene escáneres automáticos para cosas básicas como credenciales de AWS?

  • Solo si lo tienes activado. Según el artículo, este usuario había desactivado esa función

• Lo realmente triste es que el gobierno federal tenía desde hace décadas CAC, una autenticación basada en tarjetas inteligentes
  Pero como la pila pública de internet funciona sobre contraseñas, la infraestructura del gobierno terminó usando contraseñas también