Apagar automação maliciosa do GitHub pode não encerrar infecção: nova etapa do GhostAction mantém execução no computador do desenvolvedor, segundo pesquisadores

Remover um fluxo malicioso do GitHub Actions pode interromper parte do ataque GhostAction sem eliminar uma infecção já instalada no computador do desenvolvedor. A nova etapa da campanha combina arquivos inseridos em projetos com um mecanismo local capaz de buscar e executar comandos dos criminosos.

O caso foi noticiado pelo TecMundo em 19 de outubro, com base em investigação da OpenSourceMalware. A campanha usa mensagens falsas em nome do GitHub e esconde um programa de roubo de credenciais em um arquivo apresentado como fonte de texto.

O ponto decisivo é onde o código passa a rodar. Quando o ataque consegue estabelecer execução no computador, apagar a automação hospedada na plataforma não remove automaticamente os componentes locais.

Falso alerta de segurança abre caminho para o ataque

A abordagem descrita começa com um e-mail que simula um aviso de tentativa de login a partir de Moscou. A mensagem induz o destinatário a acessar um link sob o pretexto de proteger a conta.

O endereço conduz a uma página falsa que captura senha e código de autenticação de dois fatores. O processo também envolve uma autorização de aplicação que concede acesso amplo aos invasores.

Com acesso à conta, os criminosos alteram arquivos dos repositórios. O alvo inicial são as automações do GitHub Actions, usadas por desenvolvedores para tarefas como testes e verificações de código.

A segunda etapa amplia o alcance: além da automação remota, os projetos passam a carregar arquivos preparados para acionar código no ambiente de trabalho do programador.

Falsa fonte serve de disfarce para roubo de credenciais

O arquivo com aparência de fonte não está ali para mudar a tipografia de uma página. Ele contém código malicioso, acionado por uma configuração de tarefas do Visual Studio Code.

Entre os dados procurados estão credenciais de serviços de nuvem, acessos ao Git, tokens de gerenciadores de pacotes e informações de autenticação de ferramentas como Claude e Gemini.

Isso não significa que todas essas credenciais tenham sido roubadas de todos os alvos. A exposição depende dos arquivos presentes na máquina, das permissões disponíveis e do sucesso da execução.

Também não se trata, pelo mecanismo descrito, de uma infecção causada simplesmente por visualizar uma fonte no navegador. O risco está na combinação entre o projeto adulterado e a execução da tarefa que chama o conteúdo malicioso.

Execução automática no VS Code depende das permissões do ambiente

A documentação oficial do Visual Studio Code acrescenta uma condição importante à leitura do caso: tarefas automáticas não são executadas em espaços de trabalho não confiáveis.

O editor também oferece um controle específico para permitir ou impedir tarefas disparadas na abertura de uma pasta. Portanto, abrir qualquer projeto no VS Code não equivale, por si só, a autorizar toda execução descrita na campanha.

Essa proteção exige atenção à decisão de confiar no projeto e às permissões concedidas. Um repositório conhecido pode ter recebido alterações maliciosas depois de ter sido considerado seguro.

Na revisão de um projeto suspeito, as configurações do editor merecem o mesmo cuidado dedicado ao código da aplicação. Elas podem determinar quais programas serão executados durante o trabalho.

Por que apagar o workflow pode ser insuficiente

Depois de executado, o malware tenta instalar uma tarefa periódica no computador. O mecanismo descrito consulta a infraestrutura dos atacantes a cada cinco minutos para obter novos comandos.

A automação do GitHub e essa tarefa local são componentes distintos. A remoção de um não desfaz necessariamente o outro.

A consequência prática pode ser organizada em três frentes:

Essa separação ajuda a explicar por que uma limpeza apenas no site pode deixar parte do incidente sem tratamento. Também evita o erro inverso: considerar que todo repositório adulterado corresponde necessariamente a um computador infectado.

Repositórios antigos também aparecem na investigação

A pesquisa identificou um conjunto de 94 repositórios comprometidos com essa segunda etapa. Entre os projetos acessíveis analisados, 65 estavam sem alterações havia mais de um ano; um deles não recebia mudanças havia mais de nove anos.

Os números dizem respeito aos repositórios observados, não a uma contagem confirmada de pessoas ou máquinas infectadas.

O padrão descrito pelos pesquisadores sugere distribuição automatizada pelos projetos nos quais as contas comprometidas tinham permissão de escrita. Assim, um repositório esquecido também pode carregar arquivos perigosos e voltar a representar risco quando alguém retoma o trabalho nele.

Recuperação precisa alcançar contas, projetos e máquina

As recomendações divulgadas incluem revogar autorizações e tokens a partir de um dispositivo seguro, trocar senhas, revisar os repositórios e substituir chaves de serviços de nuvem potencialmente expostas.

Se houve execução local, a investigação também precisa alcançar o computador e os mecanismos de persistência. Trocar credenciais usando uma máquina ainda comprometida pode expor novamente os acessos.

Para verificar um alerta de segurança, o caminho mais seguro é acessar o GitHub diretamente, sem utilizar o link recebido por e-mail. No ambiente de desenvolvimento, revisar tarefas automáticas antes de permitir sua execução ajuda a impedir que uma configuração aparentemente rotineira acione código desconhecido.

A mudança trazida pelo GhostAction é justamente essa: o incidente pode começar em uma conta online e continuar fora dela. Encerrar o acesso na plataforma é parte da resposta, mas não demonstra, sozinho, que o computador voltou a estar seguro.

Fonte: Tecmundo