Ferramenta de código aberto da Microsoft é hackeada e usada para roubar senhas de desenvolvedores de IA

(techcrunch.com)

3 pontos por GN⁺ 4 시간 전 | 2 comentários | Compartilhar no WhatsApp

Dezenas de projetos de código aberto hospedados no GitHub foram comprometidos por hackers, com malware de roubo de senhas injetado no código, levando a Microsoft a bloquear o acesso aos projetos e iniciar uma investigação
Muitos dos projetos afetados estão relacionados a ferramentas usadas para programar com apps de desenvolvimento de IA, como o serviço de nuvem Azure e Claude Code, Gemini CLI e VS Code
Quando o usuário abre a ferramenta infectada em um app de programação com IA, ela passa a roubar senhas e credenciais sensíveis
Segundo o GitHub, pelo menos 70 projetos foram desativados, e a Microsoft removeu temporariamente alguns repositórios antes de restaurá-los após análise
O caso é mais um exemplo recente de ataque à cadeia de suprimentos mirando código aberto popular, e seria a segunda invasão de projetos open source da Microsoft em poucas semanas

Visão geral do incidente e resposta da Microsoft

Foi confirmado que hackers comprometeram projetos e injetaram malware de roubo de senhas no código, e a Microsoft está bloqueando o acesso a dezenas de projetos de código aberto no GitHub enquanto investiga como a invasão ocorreu
Muitos dos projetos afetados estão ligados a ferramentas usadas na programação de apps de desenvolvimento de IA, como o serviço de nuvem Azure e apps como Claude Code, a interface de linha de comando do Gemini e VS Code
Não foi possível confirmar imediatamente quantas pessoas de fato baixaram as ferramentas afetadas
A Microsoft confirmou que retirou repositórios do ar, fato noticiado primeiro pela 404 Media
- O porta-voz da Microsoft, Ben Hope: "removemos temporariamente alguns repositórios enquanto investigamos possível conteúdo malicioso"
- Alguns repositórios foram restaurados após revisão, e outros podem permanecer offline enquanto o trabalho continua
- A empresa notificou um pequeno número de clientes que podem ter baixado conteúdo dos repositórios afetados e, se identificar a necessidade de ações adicionais, pretende entrar em contato diretamente por meio dos canais de suporte já existentes
Em resposta à TechCrunch, a empresa não forneceu imediatamente números específicos de clientes afetados

Como o malware funciona

A empresa de segurança Cloudsmith e o site comunitário de análise de malware OpenSourceMalware estiveram entre os primeiros a apontar a invasão
O malware funciona para roubar senhas e outras credenciais sensíveis quando o usuário abre a ferramenta infectada em um app de programação com IA
Ao acessar as páginas dos projetos no GitHub, site de hospedagem de código pertencente à Microsoft, pelo menos 70 projetos apareciam com status "desativado (disabled)"
- Mensagem exibida: "O acesso a este repositório foi desativado por funcionários do GitHub devido a uma violação dos Termos de Serviço do GitHub"

O contexto de um ataque à cadeia de suprimentos

Este é o caso mais recente, em uma sequência dos últimos meses, de comprometimento de projetos de código aberto amplamente usados para instalar malware em muitos usuários que instalaram esse código
Esse tipo de invasão é chamado de ataque à cadeia de suprimentos (supply chain) e mira código usado em muitos produtos de software ou por grupos específicos de usuários
- Esses alvos podem ser atraentes para hackers por às vezes terem acesso a sistemas em nuvem e a grandes volumes de dados de clientes
Não é raro que desenvolvedores solo de projetos open source sejam alvos, e em alguns casos isso faz parte de tentativas de longo prazo para conquistar a confiança do desenvolvedor
Ainda assim, é incomum que uma grande empresa de tecnologia como a Microsoft, que dispõe de recursos para se defender desse tipo de ataque, seja comprometida

Indícios de invasões repetidas

Segundo a Ars Technica, este é o segundo caso conhecido de comprometimento de projetos open source da Microsoft nas últimas semanas
Em meados de maio, pesquisadores de segurança afirmaram que o projeto open source da Microsoft Durable Task, que ajuda desenvolvedores a criar apps, parece ter sido hackeado
O OpenSourceMalware descreveu este incidente mais recente como um "recomprometimento (re-compromise)" do projeto Durable Task
- Isso sugere que a Microsoft pode não ter removido completamente os hackers na primeira tentativa, ou que pode se tratar de uma invasão nova e totalmente separada

2 comentários

brainer 1 시간 전

Será que é por isso que, mesmo trocando a senha, eu continuo recebendo tentativas de login na minha conta da Microsoft?

GN⁺ 4 시간 전

Comentários do Hacker News

É pura especulação e observação pessoal, mas me parece que o antigo modelo RBAC já estava quase quebrado e agora parece ter quebrado de vez
Acho que o risco de cadeia de suprimentos dentro das empresas aumentou muito porque assistentes de código e engenheiros mexem em vários projetos sem relação entre si ao mesmo tempo, especialmente fazendo experimentos que antes nem davam tempo de fazer
Não estou dizendo que isso tenha relação direta, mas sinto que tem impacto, e acho que em breve também vai dar problema o fato de muitos lugares hoje incentivarem desenvolvedores e gestores a fazer IA para programação de qualquer jeito em equipamentos pessoais
É difícil acreditar que não exista um padrão em comum entre os incidentes recentes de cadeia de suprimentos, e também acho que existem grupos de hackers especializados nesse tipo de ataque porque a recompensa é grande
- Só para deixar claro, o comentário original não afirmou categoricamente que havia relação, mas isso não tem absolutamente nada a ver com IA ou vibe coding
  É uma continuação da já antiga falta de segurança na instalação de dependências de desenvolvedor e do worm Shai Halud
  Os hackers descobriram que é fácil enganar desenvolvedores para instalar alguma coisa, e que máquinas de desenvolvedor são alvos ideais porque contêm credenciais, CLIs de nuvem, MCP e outras informações sensíveis
- Na nossa empresa é parecido. Existe uma espécie de doutrina de “se você não fizer o máximo possível com IA, vai ficar para trás”
  Dá a sensação de repetir exatamente o antigo hype de IoT, correndo para ser o primeiro do grupo sem se preocupar com segurança
- Faz anos que digo que há gente de menos para a quantidade total de projetos, mas a gerência dizia que a maioria dos projetos estava ociosa e que, por isso, tudo bem cada pessoa assumir muitos
  No fim deu nisso
- Fico na dúvida se isso quer dizer que o controle de acesso baseado em papéis, ou seja, RBAC, deve ser substituído por outra coisa, ou se quer dizer que modelos específicos de RBAC usados hoje é que estão quebrados
  Pessoalmente, apesar de achar o nome um pouco confuso, vejo o modelo de segurança baseado em capacidades como o futuro
A formulação do título já é tendenciosa, e o texto também é escrito como se a culpa fosse do open source
Aí ainda fica mais engraçado porque coloca na conta da Microsoft a responsabilidade por uma tentativa de ataque à cadeia de suprimentos
Diz Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch., mas a TechCrunch não explica que open source funciona assim mesmo
Gosto de criticar a Microsoft quando dá, mas desta vez acho que a Microsoft tomou medidas seguras e corretas
O artigo escreve como se tudo fosse culpa da Microsoft e como se limitar o alcance da invasão fosse algo vergonhoso
A expressão steal passwords of AI developers também deixa uma implicação estranha sobre se seriam “desenvolvedores de IA” ou “desenvolvedores que usam IA”
A explicação sobre ataque de cadeia de suprimentos também fala só do resultado e do motivo da superfície de ataque, em vez do significado real, então acho esta cobertura muito ruim
- A TechCrunch é muito descuidada e difícil de confiar
  Já vi eles inventarem fatos para SEO ao cobrir algo em que trabalhei diretamente, e não havia nem como forçá-los a corrigir
- Não entendo qual é o problema daquela frase
  A Microsoft tem problemas organizacionais de segurança, e o fato de não conseguir travar corretamente o GitHub Actions e permitir que pull requests burlassem o CI/CD ajudou nisso ou expôs isso
  Isso é um problema da Microsoft que existe desde antes da IA e nem é controverso: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
  Na era da IA, esse problema se espalhou como endemia e está sendo transformado em arma
- Então fico curioso para saber como você vê a análise pós-incidente
  O que de fato aconteceu, e como isso deveria ser lido?
Parecem ser posts relacionados
https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
https://news.ycombinator.com/item?id=48416155
https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)
- Foi criada uma ferramenta de mitigação capaz de corrigir ou remover o worm de todos os repositórios infectados, e também foi escrito um post sobre isso
  Na segunda-feira, a campanha Hades adicionou suporte a Composer, Go e Pip. Antes disso, só dava suporte a NPM e editores com assistente de IA, e até havia Ruby, mas parece que hoje em dia quase ninguém usa Rubygems
  O ponto que nem a Microsoft percebe é que este é o primeiro worm a rodar em todas as plataformas do ecossistema de código. Ele roda em hosts de desenvolvedores, servidores e executores de CI/CD, e espalha o worm para todos os repositórios aos quais essas máquinas conseguem acessar
  Para derrotar esse worm, seria necessário desligar ao mesmo tempo 100% de todos os computadores, AWS EC2, Google Cloud Platform, Azure e clusters Kubernetes. Ele literalmente se espalha por toda a infraestrutura
  Como sempre acontece com malwares da APT28, o kill switch é definir o idioma do host como ru_RU.KOI8-R, ou seja, configurar a variável de ambiente LANG. Isso desativa o mecanismo de propagação
  Ferramenta de mitigação: https://github.com/cookiengineer/antimiasma
  Post no blog: https://cookie.engineer/weblog/articles/malware-insights-mia...
Suspeito fortemente que provavelmente foi um caso de uso desleixado de personal access tokens tradicionais
Se você vai passar tokens para um agente de IA em algum dispositivo openclaw estranho, deveria usar tokens granulares
Minha conta do GitHub está espalhada por 3 organizações com políticas completamente diferentes, e ainda me surpreende um pouco o fato de tokens classic ainda serem permitidos
No mínimo, isso deveria exigir permissão manual para cada organização
- Acho que agentes de IA deveriam ser um principal de segurança separado e receber tokens de acesso dedicados apenas para os repositórios ou organizações de que precisam
  Passar para um agente de IA um token de acesso “cunhado” para uma conta humana parece a nova versão de “anotar a senha num post-it”
- Concordo, mas o gerenciamento de permissões dos tokens granulares é quase um pesadelo
  Não é fácil determinar com exatidão o que cada tarefa precisa e o que é correto
  Além disso, muitos desenvolvedores de software acham mais importante focar no código do que nas permissões, e às vezes tratam permissões como responsabilidade de outra pessoa
- Se a causa foi um classic PAT, isso não significa que repositórios privados adicionais, além dos repositórios recentes do GitHub, também podem estar em risco?
- Estou usando um token classic de conta com baixo privilégio para scraping de repositórios públicos
  Permissões em nível de organização provavelmente atenderiam muito bem ao meu caso de uso
Ontem tive que redefinir a senha da minha conta pessoal da Microsoft. Recebi uma notificação de autenticação em duas etapas dizendo que houve uma tentativa de login da Romênia
Não sei como descobriram a senha. O único produto da Microsoft que tenho é um Xbox
Mesmo antes da IA, a Microsoft já parecia vazar por todos os lados, e seria bom se a empresa conseguisse se afastar da Microsoft, mas já estamos presos a ela
- Em contas pessoais da Microsoft, é quase impossível configurar para não permitir login sem senha
  Então, na prática, a conta provavelmente está configurada assim, e a solicitação de MFA que você recebeu talvez nem tenha sido autenticação em duas etapas, mas apenas uma tentativa de acesso à conta
  Eu também recebia várias solicitações dessas por dia, e descobri que, se você configurar o app Microsoft Authenticator no celular, ele força a mudança para um método sem senha sempre que houver algum bloqueio como rosto, impressão digital ou PIN
  Para contornar isso, é preciso desativar todos esses bloqueios durante a configuração da conta no app Authenticator
  Como quase não uso minha conta Microsoft, agora autentico por um email separado em vez do Authenticator
  O simples fato de isso funcionar assim já é uma loucura, mas imagino que alguém dentro da Microsoft esteja tentando bater alguma KPI de login sem senha
- Em algumas organizações onde trabalhei, eles faziam aparecer um prompt de autenticação multifator independentemente de a senha estar correta ou não. O objetivo era desperdiçar mais tempo do atacante
  Não tenho certeza se a Microsoft faz isso também
Queria que alguém explicasse como é possível adicionar arquivos ofuscados a tantos repositórios. Não existe revisão de código nenhuma?
O título também induz ao erro. O setup adiciona uma configuração que as pessoas que trabalham no repositório acabam executando automaticamente, e essas pessoas precisam usar VSCode, Cursor, Claude ou Gemini
Quem usa Codex, opencode ou outros harnesses de execução provavelmente está seguro
Mais detalhes: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...
- Tenho um amigo próximo que trabalha em uma grande corporação. Não posso dizer qual empresa é, mas é uma empresa do S&P 500
  Mesmo depois de trabalhar lá por bastante tempo, ele nunca viu como o projeto sob sua responsabilidade realmente é; ele tem o repositório clonado e sabe qual linguagem usa, mas fora isso não sabe mais nada
  Tudo está sendo mais ou menos remendado com IA. Esse projeto é o sistema de autenticação e autorização de todo o produto da empresa
  Segundo ele: “Passo o dia todo apertando Tab e escrevendo ‘comportamento pretendido’ nas revisões. As revisões também são todas feitas por IA e não há intervenção humana. CEO e CTO falam seriamente para fazermos assim. Se alguma coisa quebra, ninguém sabe como funciona porque ninguém olhou o código de verdade. A avaliação de desempenho não é pelo que fizemos, mas pela quantidade de tokens que usamos”
  É bem possível que muitas empresas estejam assim agora, e não é absurdo supor que não exista revisão de código de verdade
- Muitos dos commits maliciosos aparecem com o autor github-actions
  Isso significa autenticação pelo lado interno do GitHub CI/CD, e há tantos commits desse tipo que qualquer ferramenta automatizada teria dificuldade para encontrar o veneno no meio de um monte de palha
  Por isso isso está relacionado à violação de segurança do GitHub de setembro de 2025
  “As estrelas dos cinco repositórios somam 1.459, e só o mantine-datatable responde por 1.225. Estrelas são um indicador indireto grosseiro de quantos desenvolvedores fizeram checkout local do código-fonte, e esse é o grupo que este ataque mira.”
  “Todos os commits não tinham assinatura, usavam a identidade github-actions e deixavam o mesmo rastro de seis arquivos, com mensagens como chore: update dependencies [skip ci]. Vasculhar cinco repositórios em 49 segundos não é trabalho manual, é automação. Isso combina com a autopropagação do Shai-Hulud: após coletar tokens do GitHub com permissão de escrita em uma infecção anterior, ele empurra payloads persistentes para todos os repositórios alcançados por esses tokens.”
  https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
  Funcionamento real: https://safedep.io/config-files-that-run-code/
  Não tenho relação com esse pessoal, mas foi a explicação mais simples e detalhada que encontrei sobre o que está acontecendo agora
- Um colega perguntou seriamente: “Se agora a maior parte do código é gerada, então quem está realmente lendo esse código inteiro?”
  É uma empresa pequena, mas às vezes parece que algumas pessoas têm um impulso quase religioso de confiar na IA como se fosse um oráculo
  Eu leio mais de 90% do código que gero como se estivesse fazendo revisão de código de um desenvolvedor júnior
  Estou fazendo vibe coding de uma funcionalidade nova com bastante intensidade agora, mas quando os PRs do GitHub voltarem a funcionar, pretendo ler tudo minuciosamente
- Se a conta com permissão para fazer push no repositório foi comprometida, então não teria sido necessária revisão de PR
É a esse tipo de gente que estamos confiando os certificados de CA raiz do Secure Boot?
- Está falando daquela empresa que falhou na revisão de segurança de 2023? [0]
  “Cada uma das falhas descritas acima pode, isoladamente, até ser compreensível. Mas, somadas, apontam para uma falha nos controles organizacionais, na governança e na cultura corporativa de segurança da Microsoft.”
  Os produtos e serviços da Microsoft estão em toda parte. É uma das empresas de tecnologia mais importantes do mundo, possivelmente a mais importante. Essa posição exige o mais alto nível de responsabilidade global. É necessária uma cultura corporativa responsável e centrada em segurança, começando pelo CEO, para que fatores financeiros ou de time-to-market não enfraqueçam a cibersegurança nem a proteção dos clientes da Microsoft.
  “Infelizmente, ao longo desta revisão, o comitê identificou uma série de decisões operacionais e estratégicas que apontam para uma cultura corporativa na Microsoft que tratava tanto o investimento em segurança quanto a gestão rigorosa de riscos como prioridades baixas. Essas decisões causaram custos e danos significativos a clientes da Microsoft no mundo inteiro.”
  “O comitê está convencido de que a Microsoft precisa corrigir sua cultura de segurança.”
  [0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
- A raiz de confiança do Secure Boot normalmente não é um certificado da Microsoft, e sim um certificado do OEM, o que pode ser ainda pior: https://www.binarly.io/blog/pkfail-untrusted-platform-keys-u...
  De qualquer forma, você é livre para remover o certificado da Microsoft e registrar o seu próprio
- Mais do que “confiança”, é algo próximo de “ser forçado a aceitar”
  Este incidente só continua o histórico da Microsoft de não ser uma empresa que cuida bem de segurança, mas sim de ter sido o próprio problema de segurança
- Confiar na Microsoft em qualquer coisa relacionada a segurança é uma tolice
  Ela já mostrou várias vezes nos últimos 40 anos que simplesmente não se importa
Talvez eu tenha percebido isso tarde, mas já faz um tempo que digo que, mesmo que você não queira usar IA por motivos como “o código é ruim”, ainda deveria considerar usá-la para auditoria de segurança
No mínimo, é preciso usar ferramentas que façam varredura de vulnerabilidades no código
O vetor de ataque não é só plugin que rouba dados, mas também vulnerabilidades 0-day de quase todo software que você usa e script kiddies com LLM atacando seu serviço web
Os ataques vão aumentar e piorar, então é melhor repensar qualquer lugar que não invista em auditorias de cibersegurança e em ferramentas de auditoria
Ninguém deveria rodar npm install ou pip install na própria máquina
Usar sandboxing adequado de forma consistente (https://github.com/ashishb/amazing-sandbox) pode reduzir bastante o alcance do dano desses ataques
- O backend do Docker executa comandos em contêineres rootless?
  Dei uma olhada no código, mas não vi nada que confirmasse isso
- Docker não é uma estratégia séria de sandboxing
- Se a ideia é não rodar npm install ou pip install na própria máquina, qual alternativa está sendo proposta?
  Quer dizer não instalar nada fora da sandbox?
- Existe também algum componente de detecção nisso?
  Desenvolver dentro de uma sandbox é bom, mas a etapa seguinte é o deploy em produção
  Como saber se houve comportamento malicioso dentro da sandbox, para evitar distribuir ainda mais esse malware?
É engraçado demais que o GitHub da Microsoft tenha bloqueado o acesso da Microsoft Azure e de todos os outros usuários ao codebase da Microsoft por violação dos termos de uso
Isso faz a gente sentir bem a realidade desse organograma: https://www.businessinsider.com/big-tech-org-charts-2011-6