A segurança no GitHub voltou ao centro das atenções após um novo alerta divulgado pelo Datadog Security Labs, que revelou uma campanha automatizada capaz de mapear organizações, monitorar atividades de desenvolvimento e, em alguns casos, clonar repositórios utilizando credenciais comprometidas. O estudo mostra que os invasores estão explorando um recurso pouco observado pelas equipes de segurança: contas antigas e aparentemente inativas, que passam despercebidas pelos mecanismos tradicionais de detecção.
Embora boa parte da atividade observada utilize apenas informações públicas, o verdadeiro risco surge quando esse mapeamento é combinado com tokens de acesso vazados, permitindo que criminosos ampliem significativamente sua visibilidade sobre projetos privados. O resultado é um cenário preocupante para empresas que dependem do GitHub como plataforma central de desenvolvimento.
Neste artigo, você entenderá como funcionam essas contas fantasmas, de que maneira os invasores utilizam APIs públicas, GraphQL e Personal Access Tokens (PATs) para coletar informações e quais medidas podem fortalecer a segurança de repositórios dentro da sua organização.
Como funcionam os ataques com contas fantasmas no GitHub
Segundo o Datadog Security Labs, a campanha utiliza uma estratégia bastante sofisticada, porém discreta. Em vez de criar milhares de contas novas, facilmente identificáveis por sistemas antifraude, os operadores recorrem a contas antigas, muitas delas criadas há anos e sem histórico recente de atividade.
Essas contas apresentam características que dificultam sua identificação como automatizadas. Como já existem há bastante tempo, acumulam reputação suficiente para não despertar suspeitas imediatas, permitindo que realizem um grande volume de consultas antes de serem bloqueadas.
Na prática, essas contas fantasmas passam a agir como observadores silenciosos da atividade pública do GitHub. Elas acompanham organizações, usuários, projetos, alterações em repositórios públicos e relacionamentos entre desenvolvedores.
O objetivo inicial normalmente não é invadir sistemas, mas construir um enorme banco de dados sobre empresas, tecnologias utilizadas, equipes de desenvolvimento e possíveis alvos futuros.
Esse tipo de inteligência permite aos atacantes identificar projetos estratégicos, componentes críticos, bibliotecas utilizadas e até mudanças recentes na infraestrutura de software de uma organização.
Mais preocupante ainda é que toda essa coleta acontece utilizando recursos legítimos da própria plataforma, tornando extremamente difícil diferenciar uma atividade maliciosa de uma utilização comum da API do GitHub.
O abuso de APIs e consultas GraphQL
Um dos principais destaques do relatório envolve o uso intensivo da API do GitHub e das consultas via GraphQL.
Ao contrário de ataques tradicionais, que exploram vulnerabilidades ou realizam tentativas de invasão, essa campanha utiliza interfaces oficiais disponibilizadas pelo próprio GitHub para desenvolvedores.
O GraphQL permite solicitar exatamente os dados desejados em uma única consulta, tornando a coleta extremamente eficiente. Em vez de realizar centenas de requisições pequenas, um único comando pode retornar informações detalhadas sobre organizações, colaboradores, repositórios, permissões públicas e histórico de atividades.
Quando combinado com automação, esse mecanismo permite que milhares de organizações sejam analisadas continuamente, quase em tempo real.
Como todas essas operações utilizam chamadas legítimas, os sistemas de segurança precisam analisar padrões comportamentais para identificar atividades suspeitas, o que aumenta significativamente a complexidade da detecção.
Esse cenário demonstra que proteger o GitHub atualmente envolve muito mais do que impedir invasões diretas. Também é necessário compreender como informações aparentemente inofensivas podem ser utilizadas para construir inteligência sobre uma empresa.
O perigo real: De mapeamento público à clonagem de repositórios privados
O levantamento do Datadog Security Labs mostra que o verdadeiro perigo surge quando o reconhecimento obtido através das informações públicas é combinado com credenciais comprometidas.
Entre os principais alvos estão os Personal Access Tokens (PATs) e os tokens OAuth, frequentemente encontrados em vazamentos, repositórios públicos expostos ou ambientes mal configurados.
Esses tokens funcionam como credenciais de autenticação para aplicações, scripts e integrações automatizadas. Quando caem nas mãos erradas, podem oferecer acesso direto aos recursos do GitHub sem necessidade de senha.
Dependendo das permissões concedidas, um invasor pode:
- Clonar repositórios privados;
- Consultar códigos-fonte confidenciais;
- Ler documentação interna;
- Acessar pipelines de desenvolvimento;
- Obter segredos armazenados inadequadamente;
- Mapear dependências críticas da organização.
O problema se torna ainda maior quando empresas mantêm tokens antigos, esquecidos ou associados a colaboradores que já deixaram a equipe.
Em muitos ambientes corporativos, integrações criadas anos atrás continuam funcionando com credenciais que nunca foram auditadas. Esse tipo de acesso persistente representa uma superfície de ataque extremamente valiosa para criminosos.
Além do roubo de propriedade intelectual, essas informações podem alimentar ataques à cadeia de suprimentos de software, permitindo a identificação de bibliotecas internas, processos de build e componentes utilizados em produtos comerciais.
Como proteger sua organização e seus repositórios
Embora o cenário apresentado pelo relatório seja preocupante, existem diversas práticas capazes de reduzir significativamente os riscos relacionados aos ataques no GitHub.
A primeira delas é realizar uma auditoria completa de todos os Personal Access Tokens (PATs) utilizados pela organização. Tokens sem uso recente ou vinculados a integrações descontinuadas devem ser imediatamente revogados.
Também é importante revisar periodicamente todas as permissões concedidas a aplicações OAuth e GitHub Apps, removendo acessos desnecessários.
Outra medida fundamental consiste em monitorar continuamente os logs de auditoria do GitHub. Atividades incomuns, acessos realizados em horários atípicos ou grandes volumes de consultas podem indicar comportamento automatizado.
A autenticação multifator (MFA) continua sendo uma das proteções mais importantes contra comprometimento de contas. Mesmo que uma senha seja descoberta, o segundo fator reduz significativamente as chances de invasão.
Sob a perspectiva de DevSecOps, também vale adotar processos contínuos para:
- Rotacionar tokens regularmente;
- Aplicar o princípio do menor privilégio;
- Automatizar auditorias de credenciais;
- Monitorar vazamentos de segredos;
- Utilizar ferramentas de detecção de credenciais expostas;
- Revisar acessos de colaboradores desligados.
Outra boa prática é educar as equipes para evitar o armazenamento de tokens em scripts, arquivos de configuração ou repositórios públicos.
Mesmo pequenos descuidos podem transformar uma simples credencial esquecida na porta de entrada para ataques muito mais sofisticados.
Conclusão e o futuro da segurança na cadeia de suprimentos
O alerta divulgado pelo Datadog Security Labs reforça uma tendência que vem crescendo nos últimos anos: os ataques modernos não dependem exclusivamente da exploração de vulnerabilidades técnicas.
Cada vez mais, os criminosos investem em coleta silenciosa de informações, automação e exploração de credenciais legítimas para ampliar seu conhecimento sobre organizações antes mesmo de iniciar uma invasão.
Nesse contexto, a segurança no GitHub deixa de ser apenas uma questão relacionada ao código-fonte e passa a envolver também governança de acessos, monitoramento contínuo, gestão de tokens e revisão constante das permissões concedidas.
Empresas que adotam processos maduros de DevSecOps conseguem reduzir significativamente essa superfície de ataque e responder com mais rapidez diante de atividades suspeitas.
Vale a pena aproveitar este momento para revisar os Personal Access Tokens, verificar integrações antigas e confirmar se todas as contas e aplicações ainda precisam manter acesso aos seus repositórios. Pequenas ações preventivas podem evitar grandes incidentes de segurança no futuro.
