GitHub investiga exfiltração de cerca de 3.800 repositórios internos por extensão maliciosa do VS Code

Comprometimento de dispositivo de funcionário levou a acesso não autorizado a repositórios internos, com rotação de segredos críticos e monitoramento de possível atividade subsequente.

Componente	Repositórios internos do GitHub e dispositivo de funcionário com VS Code.
Vetor	Comprometimento de endpoint por uma extensão envenenada do VS Code; o nome da extensão não foi divulgado.
Impacto	Exfiltração limitada, na avaliação atual, a repositórios internos do GitHub; a alegação pública de aproximadamente 3.800 repositórios é compatível com a investigação em andamento.
Prioridade	Rotacionar segredos críticos, invalidar credenciais de alto impacto, auditar acessos a repositórios internos e procurar atividade subsequente em identidade, endpoint e rede.
Versões	Na campanha correlata de supply chain, as versões maliciosas identificadas do pacote durabletask são 1.4.1, 1.4.2 e 1.4.3.
Artefatos	Foram citados os artefatos rope.pyz, check.git-service[.]com, t.m-kosche[.]com e o mecanismo de descoberta de C2 por mensagens públicas contendo FIRESCALE.

Resumo técnico

O GitHub investiga acesso não autorizado a repositórios internos após a exposição de dados atribuída ao ator TeamPCP em fórum de crime cibernético. A atividade confirmada envolve um dispositivo de funcionário comprometido por uma extensão envenenada do VS Code, seguido de exfiltração de repositórios internos. A estimativa de aproximadamente 3.800 repositórios aparece como consistente com a apuração técnica em andamento, mas o escopo divulgado até agora não inclui evidência de impacto em empresas, organizações e repositórios de clientes armazenados fora dos repositórios internos do GitHub.

O ponto técnico central é a combinação entre acesso de desenvolvedor, extensão de editor e alcance interno de repositórios. Uma extensão maliciosa executada no ambiente de trabalho de um funcionário pode acessar contexto local, tokens, sessões, arquivos de configuração, chaves e fluxos de autenticação usados por ferramentas de desenvolvimento. Mesmo quando o atacante não obtém controle direto de sistemas de produção, a leitura de código-fonte interno, pipelines, documentação operacional ou referências a segredos pode ampliar risco de engenharia reversa, caça a credenciais e ataques subsequentes contra serviços conectados.

Fluxo técnico

A cadeia observada começa no endpoint do funcionário. A extensão maliciosa do VS Code funciona como vetor inicial porque extensões de IDE normalmente rodam com permissões do usuário, têm acesso ao workspace, podem interagir com processos locais e podem ler arquivos usados por ferramentas de versionamento, clientes de nuvem, gerenciadores de pacotes e autenticação. Se o usuário autenticado possui acesso a repositórios internos, a sessão local e os tokens disponíveis podem ser suficientes para listar, clonar, compactar ou transferir conteúdo sem explorar uma vulnerabilidade pública no GitHub. A ausência de nome público para a extensão impede atribuir a infecção a um item específico de marketplace ou a uma campanha de extensão já conhecida.

Após a contenção do dispositivo, a resposta divulgada inclui rotação de segredos críticos e priorização de credenciais de maior impacto. Essa ordem é tecnicamente coerente porque repositórios internos podem conter referências a variáveis de ambiente, documentação de implantação, exemplos de configuração, chaves antigas, URLs administrativas, nomes de serviços e scripts que permitem mapear a infraestrutura. Mesmo que segredos ativos não estejam confirmados como vazados, a exposição de código interno altera o modelo de ameaça: atacantes podem procurar fluxos de autorização, validações frágeis, dependências privadas, permissões excessivas e caminhos de build que auxiliem novas tentativas de intrusão.

A atividade ocorre em um cenário mais amplo de ataques de supply chain atribuídos ao TeamPCP, incluindo a campanha Mini Shai-Hulud. Nessa frente, o pacote durabletask, cliente Python oficial para o framework Durable Task, teve versões maliciosas identificadas em 1.4.1, 1.4.2 e 1.4.3. O caminho descrito envolve comprometimento de uma conta do GitHub em ataque anterior, extração de segredos de um repositório acessível ao usuário e uso de token do PyPI para publicar diretamente versões adulteradas. Esse fluxo mostra como um vazamento em repositório ou endpoint de desenvolvedor pode migrar rapidamente para publicação de pacote, consumo por pipelines e execução automática em ambientes de terceiros.

O payload relacionado ao durabletask foi descrito como um dropper que busca e executa a segunda etapa rope.pyz a partir de check.git-service[.]com, com fallback para t.m-kosche[.]com. A execução é condicionada a sistemas Linux e ativa um infostealer voltado a credenciais de provedores de nuvem, ferramentas de desenvolvimento, cofres de senha e arquivos locais sensíveis. Foram citadas tentativas de leitura de segredos HashiCorp Vault KV, desbloqueio ou extração de cofres 1Password e Bitwarden, acesso a chaves SSH, credenciais Docker, configurações de VPN e histórico de shell. Em ambientes AWS, a propagação usa SSM SendCommand com o documento AWS-RunShellScript; em Kubernetes, a movimentação lateral usa kubectl exec quando há credenciais e permissões disponíveis.

Superfície afetada

A superfície diretamente afetada no incidente do GitHub é composta por repositórios internos acessíveis a partir do contexto do funcionário comprometido. Não há dado público que confirme acesso a repositórios de clientes, organizações de clientes ou empresas hospedadas fora desse conjunto interno. Ainda assim, a defesa deve considerar que repositórios internos podem incluir metadados suficientes para apoiar ataques posteriores: nomes de serviços, caminhos de API, dependências privadas, automações, scripts de CI/CD, instruções de operação e referências indiretas a segredos. O risco cresce quando o mesmo endpoint mantém sessões ativas de Git, clientes de nuvem, gerenciadores de pacotes e ferramentas de produtividade autenticadas.

Na campanha de supply chain correlata, a superfície muda para qualquer estáção, servidor, contêiner ou pipeline que tenha instalado ou importado versões maliciosas do durabletask. O detalhe operacional mais crítico é que o código malicioso roda no momento da importação do pacote, sem depender de interação explícita do operador depois que a dependência entra no ambiente. Máquinas de desenvolvimento Linux, runners de CI/CD, imagens de build reutilizadas, caches de pacotes, ambientes virtuais persistentes e repositórios com lockfiles apontando para versões afetadas precisam ser tratados como potenciais pontos de exposição de credenciais.

O mecanismo FIRESCALE, usado para localizar C2 alternativo em mensagens públicas de commits no GitHub, amplia a resiliência da infraestrutura de comando e controle. Em vez de depender apenas de um domínio fixo, o malware busca um padrão em mensagens públicas e extrai dali informação de endpoint. Para defesa, isso significa que bloquear somente o domínio primário não encerra necessariamente a comunicação se o payload já estiver em execução e puder consultar a internet. Controles de saída, inspeção de processos e revogação de credenciais expostas são tão importantes quanto bloqueio de IoCs.

• Repositórios internos do GitHub acessíveis a partir do dispositivo de funcionário comprometido.
• Endpoints de desenvolvimento com extensões do VS Code instaladas e sessões autenticadas em ferramentas de código, nuvem ou pacotes.
• Ambientes Linux que instalaram ou importaram durabletask nas versões 1.4.1, 1.4.2 ou 1.4.3.
• Runners de CI/CD, caches de dependências, imagens de contêiner e lockfiles que possam reutilizar versões maliciosas.
• Ambientes AWS com permissões de SSM SendCommand e clusters Kubernetes onde credenciais permitam kubectl exec.

Hunting e telemetria

A investigação em ambientes semelhantes deve começar pelo endpoint de desenvolvedor e pela trilha de identidade. Em estáções com VS Code, procure instalação, atualização ou execução de extensões fora do catálogo aprovado, alterações recentes em diretórios de extensões, criação de processos filhos incomuns pelo editor e conexões de saída originadas do processo do editor ou de processos Python disparados por ele. Em sistemas de versionamento, revise eventos de clone, archive, download, enumeração de organizações, listagem de repositórios privados, uso de tokens fora do padrão e acessos volumosos partindo de endereço IP, agente de usuário ou horário incompatível com o comportamento do funcionário.

Para a frente de supply chain, a busca deve combinar telemetria de pacotes, processos e segredos. Registros de pip, caches locais, artefatos de build e lockfiles devem ser verificados em busca de durabletask nas versões afetadas. Em endpoints Linux e runners, procure downloads de rope.pyz, execução de Python em segundo plano, conexões para check.git-service[.]com ou t.m-kosche[.]com, tentativas de acesso a diretórios de cofres de senha, leitura de chaves SSH e chamadas de clientes de nuvem logo após a instalação de dependências. A presença de comandos aws ssm send-command, uso anômalo de AWS-RunShellScript ou execuções kubectl exec entre workloads sem mudança operacional planejada deve elevar a prioridade da resposta.

A telemetria de nuvem e CI/CD precisa focar no uso de credenciais, não apenas na presença do pacote. Tokens de PyPI, chaves de publicação, tokens GitHub, credenciais Docker, variáveis de pipeline, roles temporárias e sessões OIDC podem ter sido lidos em memória, disco ou ambiente. Eventos de criação de nova versão de pacote, publicação fora de janelas esperadas, acesso a secrets do repositório, leitura de variáveis mascaradas e tentativa de listar instâncias gerenciadas por SSM são sinais de que a infecção saiu do endpoint e alcançou o plano de automação.

• Instalação ou atualização recente de extensão do VS Code não aprovada em endpoint com acesso a repositórios internos.
• Picos de clone, archive, download ou enumeração de repositórios privados por uma mesma identidade de desenvolvedor.
• Execução ou download de rope.pyz e tráfego para check.git-service[.]com ou t.m-kosche[.]com.
• Instalação de durabletask nas versões 1.4.1, 1.4.2 ou 1.4.3 em estáções, contêineres ou runners.
• Uso inesperado de AWS-RunShellScript, SSM SendCommand ou kubectl exec após instalação de dependências Python.
• Leitura anômala de chaves SSH, credenciais Docker, configurações de VPN, histórico de shell, cofres de senha e segredos HashiCorp Vault.

Mitigação

A resposta deve tratar o endpoint comprometido como fonte de coleta de evidência e não apenas como máquina a ser reinstalada. A sequência defensiva recomendada é isolar o dispositivo, preservar artefatos de extensões do VS Code, capturar processos, conexões, histórico de comandos e tokens presentes no ambiente, e depois invalidar credenciais associadas ao usuário. A rotação deve priorizar tokens com acesso a repositórios internos, chaves de publicação de pacotes, credenciais de nuvem, segredos de CI/CD, chaves SSH e permissões que permitam movimentação lateral. Para repositórios acessados, procure segredos em histórico, ramificações, tags, artefatos e configurações de pipeline, porque a exposição pode estar fora da árvore principal do código.

No controle preventivo, organizações devem restringir extensões de IDE por lista aprovada, registrar inventário de extensões instaladas, bloquear extensões não assinadas ou não revisadas e separar identidades de desenvolvimento de identidades com permissão de publicação. Tokens de repositório e de pacote devem ter escopo mínimo, validade curta e rotação automatizada. Para GitHub, revise permissões de organizações, tokens pessoais, aplicativos OAuth, GitHub Apps, chaves de implantação e segredos de Actions. O objetivo é reduzir a utilidade de um endpoint comprometido mesmo quando o atacante executa código dentro da sessão do usuário.

Para durabletask, qualquer ambiente que instalou ou importou 1.4.1, 1.4.2 ou 1.4.3 deve ser considerado comprometido até prova em contrário. Remova a dependência afetada, substitua por versão íntegra validada pelo mantenedor quando disponível, limpe caches de pacote, reconstrua imagens de contêiner, regenere ambientes virtuais e reexecute builds a partir de bases conhecidas. Em seguida, rotacione credenciais que estavam acessíveis ao processo Python, ao runner, ao contêiner ou ao host. Bloqueios de domínio ajudam a conter comunicação, mas não substituem rotação de segredos porque o payload é projetado para colher credenciais locais e usá-las em outros serviços.

A validação final deve demonstrar que não há execução residual, que os tokens antigos falham, que permissões excessivas foram removidas e que novas instalações da dependência não recorrem a caches comprometidos. Em pipelines, force resolução limpa de dependências, verifique hashes e lockfiles, revise registros de publicação de pacotes e impeça que uma credencial de desenvolvedor consiga publicar versões sem aprovação adicional. Em nuvem, procure comandos SSM executados durante a janela do incidente, instâncias alcançadas por perfis comprometidos e alterações em workloads Kubernetes feitas por contas de serviço que normalmente não executam comandos interativos.

• Isolar o endpoint afetado, preservar evidências e remover a extensão maliciosa somente após coleta forense mínima.
• Revogar e reemitir tokens GitHub, chaves SSH, credenciais de nuvem, segredos de CI/CD e tokens de publicação de pacotes associados ao usuário ou ao runner.
• Auditar acessos a repositórios, downloads, archives, clones e enumeração de organizações durante a janela do incidente.
• Remover durabletask 1.4.1, 1.4.2 e 1.4.3, limpar caches e reconstruir ambientes que possam ter importado o pacote.
• Bloquear check.git-service[.]com e t.m-kosche[.]com, monitorando também processos Python e mecanismos de C2 alternativo baseados em FIRESCALE.
• Restringir extensões de IDE por política, aplicar escopo mínimo a tokens e exigir aprovação separada para publicação de pacotes e alteração de segredos.