Administrador da CISA vazou chaves da AWS GovCloud no GitHub

• Um repositório público Private-CISA operado por um contratado da CISA expôs credenciais de alta permissão de contas AWS GovCloud e de sistemas internos
• A conta no GitHub incluía indícios de desativação das proteções padrão contra publicação de segredos, além de senhas em texto puro, tokens e logs
• O arquivo exposto importantAWStokens continha credenciais administrativas de três servidores AWS GovCloud, e um CSV incluía dados de login de sistemas internos
• A Seralys avaliou que as chaves expostas ainda podiam autenticar com alto nível de privilégio, e que o acesso ao artifactory interno ampliava o risco de backdoor em pacotes e movimento lateral
• Logo após o aviso à CISA, a conta saiu do ar, mas as chaves AWS permaneceram válidas por mais 48 horas; a CISA disse não haver sinais de comprometimento

---

Credenciais internas da CISA expostas em repositório público no GitHub

• Um repositório público no GitHub operado por um contratado da CISA expôs várias contas AWS GovCloud de alta permissão e credenciais de sistemas internos da CISA
• O nome do repositório era Private-CISA e ele incluía até arquivos relacionados à forma como a CISA compila, testa e implanta software internamente
• O repositório continha grande volume de chaves de nuvem, tokens, senhas em texto puro, logs e outros ativos sensíveis da CISA
• Guillaume Valadon, da GitGuardian, encontrou o repositório durante o processo de varredura contínua de repositórios públicos de código para detectar segredos expostos e enviar alertas automáticos aos donos das contas
• Valadon disse que o dono do repositório não respondeu e, por causa da alta sensibilidade das informações expostas, entrou em contato com o KrebsOnSecurity

Desativação da detecção de segredos do GitHub e principais arquivos expostos

• Valadon considera este vazamento de credenciais da CISA um caso típico de má higiene de segurança
• Nos logs de commit da conta no GitHub havia indícios de que um administrador da CISA desativou a configuração padrão do GitHub que impede a publicação de chaves SSH e outros segredos em repositórios públicos de código
• Valadon relatou que havia “senhas armazenadas em CSV em texto puro, backups colocados no Git e comandos explícitos para desativar os recursos de detecção de segredos do GitHub”
• O arquivo exposto importantAWStokens incluía credenciais administrativas de três servidores Amazon AWS GovCloud
• Outro arquivo, AWS-Workspace-Firefox-Passwords.csv, continha nomes de usuário e senhas em texto puro de dezenas de sistemas internos da CISA
• Segundo Philippe Caturegli, entre esses sistemas estava também LZ-DSO, que aparentemente é a sigla de “Landing Zone DevSecOps”, o ambiente da agência para desenvolvimento seguro de código

Alto privilégio e risco de acesso a sistemas internos

• Philippe Caturegli, fundador da consultoria de segurança Seralys, afirmou que só verificou se as chaves AWS ainda eram válidas e a quais sistemas internos as contas expostas poderiam acessar
• Caturegli confirmou que as credenciais expostas podiam autenticar em três contas AWS GovCloud com alto nível de privilégio
• O arquivo arquivado também incluía credenciais em texto puro do artifactory interno da CISA
• Esse artifactory é o repositório de pacotes de código que a CISA usa para compilar software e pode ser um alvo atraente para atacantes que tentem manter persistência nos sistemas da CISA
• Caturegli avalia que esse ponto é muito adequado para movimento lateral e que, se um backdoor for inserido em pacotes de software, ele poderá ser distribuído em cada novo software compilado depois disso

Forma de uso do repositório e responsável pela gestão

• Caturegli disse que essa conta no GitHub parecia menos um repositório de projeto organizado e mais o padrão de um trabalhador individual usando-o como bloco de notas de trabalho ou meio de sincronização
• Foram usados tanto um endereço de e-mail ligado à CISA quanto um endereço pessoal, o que sugere que o repositório pode ter sido utilizado em ambientes configurados de formas diferentes
• Caturegli afirmou que, apenas com os metadados de Git disponíveis, não é possível provar quais endpoints ou dispositivos foram usados
• A análise da conta no GitHub e das senhas expostas indicou que o repositório Private-CISA era administrado por um funcionário da contratada do governo Nightwing, em Dulles, Virgínia
• A Nightwing se recusou a comentar e encaminhou as perguntas para a CISA

Resposta da CISA e duração da exposição

• Um porta-voz da CISA afirmou que a agência está ciente da exposição reportada e continua investigando a situação
• A CISA declarou que, no momento, não há indícios de que dados sensíveis tenham sido comprometidos neste incidente
• A CISA disse exigir de seus integrantes alto nível de integridade e consciência operacional e que está preparando proteções adicionais para evitar recorrência
• A CISA não respondeu às perguntas sobre o período potencial da exposição dos dados
• Segundo Caturegli, o repositório Private-CISA foi criado em 13 de novembro de 2025, e a conta do contratado no GitHub foi criada em setembro de 2018
• Logo após KrebsOnSecurity e Seralys notificarem a CISA sobre a exposição, a conta no GitHub que incluía o repositório Private-CISA ficou offline
• Caturegli disse que as chaves AWS expostas permaneceram validamente ativas por mais 48 horas depois disso, de forma difícil de explicar

Senhas fracas e risco de ampliação do comprometimento

• O repositório Private-CISA, já removido, também mostrava sinais de uso de senhas fáceis de adivinhar para vários recursos internos
• Muitas credenciais usavam senhas no formato do nome de cada plataforma seguido do ano corrente
• Caturegli considera que essa prática, mesmo sem exposição externa, pode representar uma grave ameaça de segurança em qualquer organização
• Muitas vezes, depois de conseguir acesso inicial ao sistema-alvo, invasores ampliam o alcance usando credenciais críticas expostas dentro da rede interna
• Com base no fato de que esse contratado da CISA vinha fazendo commits regulares nesse repositório desde novembro de 2025, Caturegli levantou a possibilidade de que ele estivesse usando o GitHub para sincronizar arquivos entre o notebook de trabalho e o computador de casa
• Caturegli considera que seria um vazamento constrangedor para qualquer empresa, mas, neste caso, é mais grave por se tratar da CISA

Contexto organizacional

• A CISA atualmente opera com apenas parte de seu orçamento e quadro de pessoal normais
• A CISA perdeu quase um terço de sua força de trabalho desde o início do segundo governo Trump
• Essa redução de pessoal é explicada como resultado de aposentadorias antecipadas, buyouts e demissões forçadas em várias áreas da agência
• Cobertura relacionada: CISA has lost nearly a third of its workforce

[GN⁺]

Comentários do Hacker News

• Aparentemente, o motivo de a Valadon ter entrado em contato foi que o dono não respondia e as informações expostas eram extremamente sensíveis; já é absurdo que um contratado da CISA tenha vazado credenciais, mas receber o aviso e ainda assim não responder é ainda mais grave
  Além disso, dizem que o AWS-Workspace-Firefox-Passwords.csv continha nomes de usuário e senhas em texto puro de dezenas de sistemas internos da CISA
  Entendo e lamento a situação de esvaziamento da CISA, mas um passwords.csv com senhas fracas é incompetência sem desculpa, e gerenciador de senhas nem exige um grande orçamento

  • A expressão que você procura é negligência grave
  • Não é para defender essa pessoa, mas há fortes indícios de que ela usava o GitHub como uma ferramenta de sincronização de arquivos
    Firefox-passwords.html e firefox-bookmarks.html eram arquivos exportados e depois reimportados antes de migrar para um computador novo, um método antigo de antes do Firefox Sync existir
    O artigo também menciona isso, mas chama a atenção a ponto de valer destacar
  • De um lado, a CISA está sendo reduzida; do outro, a retórica sobre cibersegurança, interesse nacional e infraestrutura crítica só continua crescendo
  • A maioria das pessoas conhecidas que eu tinha na CISA foi dispensada durante a campanha DOGE entre janeiro e março de 2025
    Foi algo no estilo “nós, na faixa dos 20 anos, não sabemos o que você faz, então está demitido”, sem qualquer aviso prévio
    Até a equipe que lidava com vulnerabilidades de segurança em urnas Diebold e com invasões de implantes estrangeiros desapareceu
  • A primeira “invasão” que denunciei foi encontrar um arquivo de senhas em texto puro na rede de computadores do meu colégio, e isso foi em 1987
    O mundo muda, mas certas coisas continuam iguais

• Uma das coisas que as pessoas subestimam é o quanto se manda segredo para OpenAI, Anthropic e OpenRouter quando se deixa .env ou outros segredos no disco dentro do repositório, mesmo sem fazer commit
  O LLM pode perfeitamente ler os arquivos inteiros e depois mandar isso para os dados de treinamento do ChatGPT sem mostrar qualquer aviso
  Porque, à primeira vista, parece uma tarefa normal verificar se as variáveis de ambiente estão configuradas ou se a senha do banco de dados do app está pronta
  Agora as organizações precisam auditar e rotacionar segredos armazenados em disco ou em logs, e migrar para ferramentas como SOPS ou Vault para evitar deixá-los em texto puro fora dos momentos em que forem realmente necessários

  • Esse problema é muito mais subestimado do que parece
    O caminho do vazamento normalmente não é “alguém fez commit de um segredo”, mas algo mais como “o agente leu o .env ao responder e incluiu os valores na análise, e esse prompt e essa conclusão foram parar em dados de treino ou no cache de alguém”
    Em projetos com segredos reais, colocamos .env, credentials/ e .pem em .aiignore ou .claudeignore, escrevemos nos arquivos de instruções por projeto para “não ler arquivos .env mesmo se isso for pedido”, e fazemos com que os segredos sejam injetados como variáveis de ambiente no início do processo a partir do 1Password ou do keychain, não do disco
    O problema maior é que “respeite o .gitignore” é a abstração errada
    Em repositórios privados, há muitos arquivos que até podem ser commitados, mas não deveriam ir parar numa API de LLM, e os dois conjuntos não são iguais
  • Sendo justo, um arquivo .env na árvore de desenvolvimento não deveria conter segredos realmente importantes
    Deveriam ser segredos de desenvolvimento com acesso restrito, e mesmo valores que levem a sistemas de “produção”, como num ambiente de desenvolvimento da OpenAI, deveriam ter privilégios limitados sempre que possível
    Não é só vazamento: durante testes e desenvolvimento, também é fácil causar uma negação de serviço no sistema por engano ou enviar requisições erradas
    É melhor evitar situações em que alguém, ao mexer em automação de testes, acaba disparando milhares de resultados reais por acidente e recebe uma fatura de 1 mil dólares
  • Concordo. Credenciais fixas de longa duração são o problema real
    É louvável que a AWS e outras grandes nuvens tenham criado ferramentas para sair disso e até ofereçam incentivos suaves ou bem fortes
    Mas nem todo mundo chegou ao nível necessário
    Por exemplo, a Railway não permite acessar recursos da AWS com papel/OIDC; abri um ticket sobre isso, mas ainda não vi movimento
    0: https://station.railway.com/feedback/allow-for-integration-w...
  • Eu não deixo mais arquivos dotenv em texto puro
    Mantenho arquivos de ambiente criptografados com sops e uso ferramentas como direnv para disponibilizá-los no shell durante o trabalho
    Claro, o LLM ainda pode acabar exibindo esses segredos, mas a chance diminui
    Além disso, pelo menos o Claude parece tentar evitar ler dotenv; e, por fim, os segredos locais em si não deveriam ser tão importantes assim
    Use escopo limitado, contas de desenvolvimento etc.
  • Pelo que vi recentemente, pelo menos o Claude se esforça bastante para não ler arquivos de ambiente
    Por exemplo, para fazê-lo ler e acessar um banco de dados, você precisa forçar bastante isso no prompt

• Em 2026, se você está guardando credenciais do governo em um repositório e nem tem um scanner para detectar isso, deveria ser investigado
  Tenho uma desconfiança enorme de quem faz esse tipo de coisa em função profissional
  Se um serviço de inteligência estrangeiro visse isso, acho que a primeira reação seria achar que era um honeypot; seria tão óbvio que pareceria uma armadilha sem criatividade

  • Ainda bem que demitiram todas as pessoas competentes do governo
  • Já sabemos que a DOGE tentou extrair dados do governo dos EUA, como a totalidade dos funcionários do governo federal ou todos os números de seguridade social
    Em administrações anteriores, eu acharia que a CISA estava fazendo alguma operação de engodo, mas considerando a corrupção e a incompetência deste governo, além das demissões em massa na CISA, talvez seja mesmo só um erro real

• Também subiram documentos sensíveis no ChatGPT [1]
  [1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...

  • Lendo essa matéria, parece que Trump/Noem encheram os cargos de espiões estrangeiros
    Um dia o povo americano vai cobrar responsabilidade por isso

• Ironicamente, com essa chave da AWS dava para usar vários serviços da AWS de forma mais segura
  Por exemplo, S3, de preferência S3 com KMS, Parameter Store, EBS, EFS, AWS Secrets Manager, ou até simplesmente criptografar os arquivos diretamente com KMS
  Na verdade, qualquer serviço da AWS que suporte KMS e não exija conceder acesso à chave ao principal de serviço serviria

• O mais surpreendente é isso ter durado 6 a 7 meses
  Eu imaginava que empresas como GitGuardian ou pesquisadores independentes usando trufflehog encontrariam chaves vazadas em poucos dias
  Talvez o GitHub tenha crescido tanto que os scanners já não consigam acompanhar

• O nome do repositório era literalmente Private-CISA
  Seria interessante procurar nomes de repositório com palavras como private, internal, e também nomes de órgãos do governo ou empresas não técnicas que normalmente não apareceriam em nomes de repositório
  Daria até para clonar tudo e usar um LLM para fazer uma varredura rápida em busca de conteúdo interessante
  Mas o GitHub não tem scanner automático pelo menos para o básico, como credenciais da AWS?

  • Só se estiver ativado. Segundo o artigo, esse usuário tinha desativado o recurso

• O realmente lamentável é que o governo federal já tinha, desde décadas atrás, o CAC, uma autenticação baseada em smart card
  Mas como a pilha da internet pública roda em cima de senhas, a infraestrutura do governo também acaba usando senhas