73 repositórios da Microsoft no GitHub ficam indisponíveis após ataque hacker
- Cyber Security Brazil
- há 2 dias
- 4 min de leitura

Repositórios da Microsoft no GitHub foram afetados por uma nova etapa da campanha Miasma, um ataque autorreplicante contra a cadeia de suprimentos de software que vem se espalhando por projetos open source e ambientes de desenvolvimento. Segundo a OpenSourceMalware, o incidente impactou 73 repositórios da Microsoft distribuídos em quatro organizações no GitHub: Azure, Azure-Samples, Microsoft e MicrosoftDocs.
Após a identificação da atividade, o GitHub desabilitou o acesso aos repositórios afetados. Ao tentar acessar o repositório “Azure/azure-functions-host”, por exemplo, a plataforma passou a exibir uma mensagem informando que o acesso havia sido bloqueado pela equipe do GitHub por violação dos termos de serviço.
Entre os repositórios impactados, a OpenSourceMalware citou projetos como azure-search-openai-demo-purviewdatasecurity, Connectors-NET-LSP, Connectors-NET-SDK, durabletask, durabletask-dotnet, durabletask-go, durabletask-js, durabletask-mssql, functions-container-action, homebrew-functions, llm-fine-tuning e windows-driver-docs.
Um dos pontos mais relevantes do caso é a nova exposição do pacote “durabletask” no PyPI, que já havia sido comprometido no mês anterior pelo grupo TeamPCP para entregar um malware de roubo de informações em sistemas Linux. Para o pesquisador Paul McCarty, conhecido como 6mile, o fato de o repositório ligado ao comprometimento anterior aparecer novamente no centro da nova onda de remoções indica uma continuidade preocupante.
Segundo McCarty, não apenas o repositório Azure/durabletask deixou de estar acessível, mas também diversos projetos relacionados ao ecossistema Durable Task, incluindo implementações em .NET, Go, Java, JavaScript, MSSQL, Netherite e protobuf, além do monitor do Durable Functions. Para ele, quando o repositório na origem do comprometimento anterior se torna o ponto central da nova derrubada, isso sugere que a falha inicial pode não ter sido totalmente contida.
A campanha Miasma é avaliada como uma variante do worm Mini Shai-Hulud, divulgado publicamente pelo TeamPCP em meados de maio de 2026. Desde então, o malware continuou evoluindo, refinando suas táticas e infectando novos pacotes ao longo dos últimos dias. Parte da operação envolve a criação de repositórios públicos que armazenam segredos roubados, usando descrições como “Miasma: The Spreading Blight”, “Miasma : The Spreading Blight”, “Miasma - The Spreading Blight” e “Hades - The End for the Damned”.
No momento descrito pelo relatório, havia 13 repositórios com a descrição “Hades - The End for the Damned” e 82 repositórios usando os três padrões restantes relacionados ao nome Miasma. Esse comportamento reforça a natureza autorreplicante da campanha, na qual credenciais, chaves e segredos expostos podem ser reutilizados para comprometer novos projetos e ampliar a propagação.
A atividade também foi observada fora do fluxo tradicional de envenenamento de pacotes em registries como o npm. Em vez de publicar pacotes maliciosos no registro, os invasores inseriram código diretamente no repositório “icflorescu/mantine-datatable” e em quatro projetos relacionados: “mantine-contextmenu”, “next-server-actions-parallel”, “mantine-datatable-v6” e “mantine-contextmenu-v6”.
De acordo com a SafeDep, o commit malicioso não adicionou novas dependências. Em vez disso, implantou um executor de payload de 4,3 MB e o configurou para execução automática por meio de cinco ferramentas usadas por desenvolvedores: Claude Code, Gemini CLI, Cursor, VS Code e o script de teste do npm. Na prática, o ataque é acionado quando um desenvolvedor clona um dos repositórios afetados e o abre em um agente de codificação com inteligência artificial.
A SafeDep afirmou que o dropper usado nessa etapa é o mesmo loader Bun em estágios, agora adaptado para persistência diretamente em repositórios de código-fonte no GitHub, em vez de envenenamento de registries de pacotes. Essa mudança amplia a superfície de ataque, pois explora o fluxo de trabalho cotidiano de desenvolvedores que utilizam IDEs, agentes de IA e automações locais para revisar, testar ou modificar código.
O caso evidencia fragilidades estruturais no modelo de confiança que sustenta a entrega de software em ecossistemas open source. Em vez de explorar uma vulnerabilidade específica no GitHub ou no npm, a campanha abusa de credenciais válidas, mantenedores autenticados e processos legítimos de publicação ou alteração de código. Isso dificulta a detecção, já que a atividade maliciosa pode parecer, do ponto de vista das plataformas, uma atualização regular feita por um usuário autorizado.
A FalconFeeds.io observou que a força do worm está justamente em operar por canais legítimos. Segundo a análise, ele não explora uma falha técnica no npm ou no GitHub, mas sim o modelo de confiança dessas plataformas, baseado na premissa de que um pacote assinado por uma chave válida e publicado por um mantenedor autenticado é seguro.
No caso do Shai-Hulud e de suas variantes, como o Miasma, o ataque compromete a chave e o mantenedor para agir como um publicador legítimo. Assim, cada publicação maliciosa pode se confundir com uma atualização de rotina, tornando defesas convencionais menos eficazes contra uma campanha que se propaga por meio da própria infraestrutura confiável do ecossistema de desenvolvimento.
A recorrência envolvendo o ecossistema Durable Task também chama atenção para a dificuldade de erradicar totalmente incidentes de cadeia de suprimentos quando credenciais, tokens, chaves de publicação ou acessos de mantenedores permanecem válidos após o primeiro comprometimento. Em ataques desse tipo, a contenção exige mais do que remover pacotes maliciosos: é necessário revisar credenciais, rotacionar segredos, auditar permissões, verificar histórico de commits e avaliar possíveis comprometimentos em projetos downstream.
Com a adoção crescente de agentes de IA no desenvolvimento de software, a campanha também aponta para um vetor emergente: o abuso de ferramentas que executam, analisam ou interagem com código automaticamente. Quando um repositório malicioso é aberto em um ambiente integrado a assistentes de codificação, scripts e extensões podem se tornar parte da cadeia de execução, reduzindo a distância entre o simples ato de clonar um projeto e a ativação de um payload.