Na semana passada, o GitHub lançou a revogação de credenciais de autoatendimento para o Enterprise. O recurso permite que os proprietários de organizações desativem credenciais comprometidas em toda a organização em uma única ação, em vez de tentar rastrear tokens individuais durante um incidente ativo.
Essa correção era algo esperado há muito tempo, pois os últimos meses mostraram o que acontece quando a revogação é lenta ou incompleta. O comprometimento do Trivy em março voltou para uma segunda rodada porque a primeira limpeza deixou pelo menos uma credencial ativa, e essa cascata atingiu a Checkmarx dias depois. Em junho, os próprios repositórios durabletask da Microsoft foram atingidos por meio de uma conta que nunca foi totalmente limpa após um ataque anterior.
A Microsoft tem estado em uma onda de correções de segurança ultimamente. Eles nos deram períodos de espera para publicação após alterações de conta poucos dias antes disso, e no início de junho também atualizaram o npm para interromper scripts postinstall automáticos. Estaremos atentos ao que mais eles lançarem e como isso impacta os ataques a softwares de código aberto.
O que o GitHub lançou
Proprietários de Enterprise com a permissão "Manage enterprise credentials" agora podem revogar em massa ou excluir credenciais para todos os usuários na organização, ou direcionar uma conta específica. Isso abrange autorizações SSO para Personal Access Tokens (PATs), chaves SSH e tokens OAuth. Uma opção de exclusão em massa está disponível para organizações de Enterprise Managed Users (EMU), e APIs REST em nível de organização lidam com revogação mais granular por organização. Cada ação cria uma entrada de log de auditoria e envia notificações por e-mail aos usuários afetados.
Membros individuais obtêm uma nova visualização em Configurações > Credenciais, mostrando todas as credenciais vinculadas à sua conta, autorizadas por SSO e pessoais. A partir daí, uma única ação remove o acesso de todas essas credenciais a recursos corporativos protegidos por SSO em uma única etapa, eliminando o processo demorado de percorrer uma lista de tokens um por um. Membros de organizações EMU também recebem uma opção separada para excluir permanentemente todos os seus tokens e chaves SSH.
Antes desse recurso break glass, era necessário trabalhar com algumas ferramentas diferentes para desativar as credenciais de uma conta. PATs de granularidade fina podiam ser revogados na tela de tokens da organização. Tokens clássicos só podiam ser desativados por meio da revogação de autorização SSO por token, e apenas se o SAML SSO estivesse ativado. A API de revogação de credenciais poderia eliminar um token, mas apenas se você já tivesse a string do token em mãos, o que funciona no caso de segredo vazado, não no caso de conta comprometida (isso arranha a superfície das complexidades, mas vamos parar por aqui). O ponto é que isso resultava em uma tentativa bastante confusa de coordenar as alterações de credenciais.
NB: Tokens do GitHub Actions estão fora do escopo aqui, pois são gerados por trabalho e expiram quando o trabalho termina, então não há nada a ser revogado. A maneira de limitar os danos durante um incidente é desabilitar o Actions no repositório.
Por que agora?
Ataques recentes de malware têm atingido a Microsoft de perto.
Em 19 de maio, atacantes usaram credenciais previamente roubadas para enviar três versões maliciosas do pacote da Microsoft durabletask pacote para o PyPI, parte da campanha do worm Miasma. A Microsoft removeu os pacotes em poucas horas. No entanto, em 5 de junho, a mesma conta enviou um commit malicioso para o repositório GitHub `Azure/durabletask`, plantando o worm novamente. O GitHub respondeu desabilitando 73 repositórios em quatro das organizações GitHub da Microsoft. Isso incluiu as ferramentas do Azure Functions que muitas equipes utilizam para deploy, quebrando pipelines de CI/CD além da Microsoft. Pesquisadores listam algumas explicações possíveis para a repetição, mas a principal é que as credenciais de maio nunca foram totalmente rotacionadas. Uma empresa de monitoramento encontrou posteriormente as credenciais do GitHub da conta em logs de infostealer desde abril. Qualquer que seja o mecanismo exato, a mesma conta foi usada em ambos os comprometimentos.
Mas isso não é novo, e o problema já apareceu várias vezes este ano. No final de fevereiro de 2026, um malicioso bot de IA explorou um pull_request_target fluxo de trabalho do GitHub Actions no repositório do Trivy, que permitiu ao atacante roubar um PAT com acesso de escrita a mais de 33 workflows em toda a organização GitHub da Aqua Security. A Aqua Security descobriu a violação e rotacionou as credenciais. Mas, infelizmente, a rotação não foi completa, e as credenciais não foram todas revogadas simultaneamente.
Em 19 de março, os atacantes usaram credenciais que sobreviveram à rotação incompleta para forçar o push de 75 de 76 tags de versão em aquasecurity/trivy-action para commits maliciosos. O payload foi executado antes da varredura real do Trivy em cada pipeline, então todos os workflows pareciam ser concluídos normalmente. Pipelines de CI/CD executando Trivy estavam coletando credenciais de seus próprios runners, como chaves SSH, credenciais de Cloud, tokens Kubernetes e PATs do GitHub.
Quatro dias depois, credenciais roubadas desses pipelines foram usadas para envenenar o GitHub Actions da Checkmarx com um payload de roubo idêntico. A Checkmarx confirmou que a atividade do ator da ameaça persistiu em seu ambiente até 22 de abril, com seus dados exfiltrados publicados na dark web em 25 de abril.
Toda essa cadeia de Trivy para Checkmarx remonta à rotação incompleta. Se a Aqua Security tivesse sido capaz de cortar instantaneamente todas as credenciais para a conta de serviço comprometida após a violação de fevereiro, o ataque teria parado ali.
Rotação atômica, o quê?
Rotação atômica significa trocar uma credencial como uma única operação de tudo ou nada, de modo que não há um momento em que as credenciais novas e antigas funcionem. O objetivo é evitar qualquer tempo de inatividade no sistema. Isso é legal na teoria. Em um sistema distribuído, não é assim que funciona. Há muita coordenação envolvida. Na escala de uma organização como o GitHub, a rotação atômica é sem sentido.
Então, a rotação real escolhe um de dois caminhos, ambos imperfeitos. A rotação de rotina mantém ambas as credenciais válidas por um período para que nada quebre, o que é bom quando não há problemas, mas deixa a credencial antiga ativa. A resposta a incidentes faz o oposto, cortando a credencial antiga instantaneamente e aceitando que as coisas quebrem até que você a reemita.
Um botão de 'break-glass' permite que você faça a única coisa que é realmente atômica, que é simplesmente eliminar todas as credenciais no escopo de uma vez. Claro, isso quebra o CI/CD. Mas tirar um atacante da sua infraestrutura é muito mais importante e vale algumas horas ou dias de builds quebrados.
Até agora, cortar todas as credenciais de uma vez era difícil de executar. Este novo corte de uma única ação é o que o torna executável sob pressão, e embora a rotação atômica completa ainda seja bastante elusiva, isso nos aproxima do mundo ideal.
O que fazer
Na sua organização GitHub, confirme se a permissão "Manage enterprise credentials" está atribuída a alguém que possa agir imediatamente, e faça isso antes que ocorra um incidente. Revise Configurações > Credenciais agora para entender o que está no escopo.
Além disso, enquanto você estiver atualizando suas configurações de segurança, fixe seus GitHub Actions em SHAs de commit completos, em vez de tags de versão. As tags podem ser forçadas a apontar para um código inteiramente diferente, o que é a técnica central por trás do comprometimento do Trivy. Um SHA de commit fixado não pode ser movido.
A Aikido Security monitora suas aplicações em busca de pacotes comprometidos em tempo real. Quando algo em seu pipeline é envenenado, você recebe um alerta antes que o coletor de credenciais seja executado. Isso é alimentado pelo Aikido Intel, que analisa novas versões de pacotes assim que são lançadas.
Obrigado por todas as atualizações, Microsoft. Por favor, continue enviando-as. 🙏
