Ataque automatizado inseriu 5.718 commits em 5.561 repositórios para executar workflows do GitHub Actions capazes de exfiltrar segredos de CI, credenciais de nuvem, chaves SSH, tokens OIDC e código-fonte.
| Componente | Repositórios GitHub e pipelines do GitHub Actions, incluindo o caso citado do pacote @tiledesk/tiledesk-server. |
| Vetor | Commits maliciosos enviados por contas descartáveis, identidades de autor falsificadas e possível uso de PATs ou deploy keys comprometidos para inserir arquivos de workflow com payload Bash codificado em Base64. |
| Impacto | Execução dentro de runners de CI/CD após merge ou acionamento manual, com tentativa de exfiltração de segredos de CI, credenciais de nuvem, chaves SSH, tokens OIDC, arquivos de configuração e segredos presentes no código-fonte. |
| Prioridade | Auditar commits e workflows adicionados em 18 de maio de 2026, revogar credenciais expostas, revisar PATs e deploy keys, bloquear workflows suspeitos e reduzir permissões de GITHUB_TOKEN. |
| Artefatos | Autores forjados build-bot, auto-ci, ci-bot e pipeline-bot; nomes de usuário descartáveis com oito caracteres, como rkb8el9r, bhlru9nr e lo6wt4t6; variantes SysDiag e Optimize-Build. |
| IoC | Servidor de comando e controle indicado como 216.126.225[.]129:8443. |
A campanha Megalodon atingiu a cadeia de desenvolvimento ao inserir workflows maliciosos do GitHub Actions em escala incomum. Em uma janela de aproximadamente seis horas, em 18 de maio de 2026, entre 11h36 e 17h48 UTC, foram enviados 5.718 commits contra 5.561 repositórios distintos. O objetivo técnico descrito é levar código controlado pelo atacante para dentro dos pipelines de CI/CD, onde normalmente existem tokens de automação, credenciais temporárias de nuvem, chaves SSH, permissões para publicação de artefatos e acesso a variáveis de ambiente. A campanha não depende do usuário instalar um pacote no endpoint local; o ponto crítico é a execução do workflow no ambiente de integração contínua do projeto comprometido.
Os commits foram construídos para parecer manutenção comum de automação. A operação alternou identidades de autor como build-bot, auto-ci, ci-bot e pipeline-bot, além de mensagens de commit que imitavam ajustes rotineiros de CI. A falsificação do autor via configuração Git não equivale, por si só, à tomada da conta nominal usada no campo de autoria; ela serve para reduzir atrito visual durante a revisão. O envio dos commits é atribuído a contas descartáveis do GitHub, com nomes aleatórios de oito caracteres, e a pushs realizados por meio de PATs ou deploy keys comprometidos. Esse detalhe desloca a resposta defensiva para duas frentes: inspeção de conteúdo no repositório e validação das credenciais que permitiram a escrita.
O payload observado é um Bash codificado em Base64 dentro de arquivos de workflow. Após decodificação e execução pelo runner, a lógica busca segredos de CI, credenciais de provedores de nuvem, chaves SSH, tokens OIDC e segredos presentes no código. A coleta também inclui arquivos como .env, credentials.json, service-account.json e outros artefatos de configuração, além de chaves de API, strings de conexão com banco de dados, JWTs, chaves privadas PEM e tokens detectados por mais de 30 padrões de expressão regular. A infraestrutura de exfiltração indicada no material técnico é 216.126.225[.]129:8443, que deve ser tratada como indicador para investigação histórica e bloqueio quando aplicável.
O fluxo começa com a obtenção de capacidade de escrita em repositórios. O material analisado aponta uso de contas descartáveis e pushs viabilizados por PATs ou deploy keys comprometidos. Com essa permissão, o atacante adiciona ou altera arquivos de GitHub Actions para incluir um comando Bash codificado em Base64. O uso de codificação não torna o payload sofisticado, mas dificulta a leitura casual durante revisão de diff, principalmente quando o commit se apresenta como atualização de pipeline. Em repositórios com revisão superficial de mudanças em .github/workflows, uma alteração pequena pode passar como ajuste operacional, mesmo alterando profundamente o comportamento executado no runner.
Foram descritas duas variantes. A SysDiag é uma variante massiva que adiciona um novo workflow acionado em cada push e pull_request. Esse desenho maximiza execução, porque qualquer nova alteração ou abertura de pull request pode disparar o payload. A desvantagem operacional para o atacante é produzir mais ruído, já que execuções repetidas deixam trilhas em logs de Actions, eventos de workflow e tráfego de saída. A Optimize-Build é mais restrita: ela depende de workflow_dispatch, recurso do GitHub Actions que permite executar manualmente um workflow sob demanda. No caso citado de @tiledesk/tiledesk-server, o foco foi atingir runners de CI/CD por esse caminho, sem acionar a cadeia quando o pacote npm é instalado.
A escolha por workflow_dispatch reduz a superfície de execução automática, mas pode aumentar o controle do operador. Em um volume de mais de 5.500 repositórios comprometidos, mesmo uma fração pequena de projetos com GITHUB_TOKEN utilizável, segredos úteis ou permissões mal configuradas já cria uma base suficiente para disparos seletivos. Uma vez que o commit é aceito ou permanece no ramo monitorado, a execução ocorre no contexto legítimo do repositório. Isso é especialmente sensível porque runners de CI frequentemente herdam segredos por ambiente, permissões de publicação, acesso a registros de pacotes, credenciais para nuvem e capacidade de ler o checkout completo do código.
A etapa de coleta também alcança metadados de nuvem. O payload descrito tenta obter credenciais de função de instância consultando endpoints de metadados da AWS com IMDSv2, o serviço de metadados do Google Cloud e o Azure Instance Metadata Service. Esse comportamento indica que a campanha não se limita ao GitHub como plataforma: ela tenta transformar a execução temporária em runner ou ambiente de build em acesso a identidades de nuvem, caso o runner esteja em infraestrutura com perfil associado. O impacto, portanto, pode ir de roubo de segredos de repositório até expansão para contas de cloud, registros de artefatos, bancos de dados ou ambientes de implantação, dependendo do que estava acessível no momento da execução.
A superfície principal são repositórios GitHub que aceitaram commits maliciosos em arquivos de workflow, especialmente dentro de .github/workflows. Projetos com automações que executam em push, pull_request ou workflow_dispatch precisam revisar tanto a presença de novos workflows quanto alterações em workflows existentes. A exposição aumenta quando o repositório permite tokens com escrita ampla, deploy keys reaproveitadas, PATs sem escopo mínimo, ausência de revisão obrigatória para mudanças de CI ou runners capazes de acessar segredos em eventos acionados por alterações não confiáveis.
O caso de @tiledesk/tiledesk-server demonstra que o risco pode estar no repositório de desenvolvimento, não necessariamente no consumidor do pacote. O fato de um pacote ter sido citado não significa, pelo material analisado, que todo usuário que instalou o pacote executou o payload; a variante indicada mira runners por workflow. Essa distinção é importante para resposta: consumidores devem monitorar alertas do ecossistema, mas mantenedores e organizações que operam o repositório precisam priorizar auditoria de Actions, credenciais, histórico de execução e logs de rede do ambiente de build.
A campanha também se conecta a um cenário mais amplo de ataques contra a cadeia de software. O contexto menciona atividade atribuída a TeamPCP em ecossistemas de código aberto, com comprometimento de ferramentas populares e extorsão em alguns casos, além de efeitos colaterais que levaram o npm a invalidar tokens granulares com acesso de escrita que contornavam autenticação de dois fatores. Também foi citada uma operação separada envolvendo a conta descartável polymarketdev, que publicou nove pacotes npm maliciosos para se passar por ferramentas CLI de negociação da Polymarket e coletar chaves privadas Ethereum/Polygon via gancho postinstall. Esses eventos não devem ser misturados como um único incidente, mas mostram que tokens, pipelines e scripts de instalação seguem sendo alvos centrais.
- Repositórios com commits em 18 de maio de 2026 entre 11h36 e 17h48 UTC, especialmente quando o diff altera
.github/workflows. - Workflows acionados por
push,pull_requestouworkflow_dispatchque contenham Bash codificado em Base64 ou comandos de coleta de segredos. - Credenciais com capacidade de escrita no GitHub, incluindo PATs e deploy keys, que possam ter permitido pushs por contas descartáveis.
- Runners com acesso a variáveis de ambiente, arquivos
.env,credentials.json,service-account.json, chaves SSH, tokens OIDC e serviços de metadados de nuvem.
A investigação deve começar pelo controle de versão. Procure commits que adicionem workflows com nomes aparentemente administrativos, autores build-bot, auto-ci, ci-bot ou pipeline-bot, e mensagens de commit ligadas a manutenção de CI. A autoria Git precisa ser correlacionada com a identidade autenticada que realizou o push, porque o campo de autor pode ter sido forjado. Em organizações GitHub, a telemetria de auditoria deve ser usada para localizar criação, uso ou alteração de PATs, deploy keys e contas que realizaram pushs incomuns. A presença de nomes de usuário aleatórios com oito caracteres, como rkb8el9r, bhlru9nr e lo6wt4t6, é um padrão útil para busca, mas não deve ser o único critério.
Nos logs do GitHub Actions, investigue execuções recém-criadas, workflows executados manualmente por workflow_dispatch, jobs que decodificam Base64, invocam Bash de forma indireta ou acessam arquivos de configuração sensíveis. O conteúdo do payload pode ter variado, então a busca por strings exatas deve ser combinada com análise comportamental: leitura recursiva do workspace, enumeração de variáveis de ambiente, consulta a serviços de metadados de nuvem e conexões de saída para 216.126.225[.]129:8443. Quando houver runners auto-hospedados, logs do sistema operacional e proxy de saída ajudam a diferenciar uma execução em runner efêmero de possível persistência ou reuso de credenciais fora do job.
Para nuvem, a telemetria deve focar chamadas realizadas logo após execuções de CI suspeitas. Se credenciais de função de instância foram expostas, podem aparecer eventos de uso de identidade fora do padrão, criação de tokens de sessão, enumeração de recursos ou acesso a segredos gerenciados. Em AWS, Google Cloud e Azure, a consulta aos endpoints de metadados por processos de build deve ser tratada como sinal forte quando o pipeline não precisa explicitamente desse mecanismo. Para repositórios com publicação de pacotes, verifique também tentativas de publicação, alteração de tags, criação de releases e acesso a registros externos após o horário dos commits maliciosos.
- Commits adicionando ou alterando arquivos em
.github/workflowscom payload Bash codificado em Base64. - Execuções de
workflow_dispatchinesperadas ou jobs iniciados logo após merges de commits de manutenção de CI. - Tráfego de saída de runners para
216.126.225[.]129:8443. - Leitura de
.env,credentials.json,service-account.json, chaves PEM, tokens OIDC, chaves SSH e variáveis de ambiente sensíveis durante jobs de CI. - Consultas a endpoints de metadados da AWS IMDSv2, Google Cloud metadata e Azure IMDS a partir de runners.
A primeira medida é impedir novas execuções. Repositórios suspeitos devem ter workflows recém-adicionados desabilitados ou removidos, principalmente aqueles que usam push, pull_request e workflow_dispatch sem justificativa operacional clara. Em seguida, revise o histórico de commits da janela indicada e compare mudanças em .github/workflows com aprovações de revisão. Se o commit malicioso foi incorporado, trate todos os segredos disponíveis ao runner como potencialmente expostos. A remoção do arquivo malicioso não revoga credenciais já coletadas; por isso, rotação deve ocorrer antes de encerrar a resposta.
A rotação precisa cobrir segredos do GitHub, tokens de registros de pacotes, chaves SSH, credenciais de cloud, tokens OIDC mal configurados, strings de conexão e arquivos de conta de serviço. PATs e deploy keys com escopo amplo devem ser substituídos por mecanismos de menor privilégio e revisados quanto a origem, dono, data de criação e último uso. Quando possível, GITHUB_TOKEN deve operar com permissões mínimas por workflow, e jobs que não precisam escrever no repositório não devem receber escrita por padrão. Ambientes de implantação devem exigir proteção adicional, como aprovação manual e separação entre build e deploy.
Runners auto-hospedados exigem contenção específica. Se um runner executou workflow suspeito, avalie descarte ou reconstrução da máquina, revisão de caches, limpeza de diretórios de trabalho e inspeção de credenciais locais. Caches de dependências, artefatos de build e logs podem conter segredos coletados ou comandos executados, mas também podem armazenar evidências necessárias para o escopo do incidente. Em runners efêmeros, concentre a análise em logs de Actions, tráfego de rede, eventos de identidade e uso subsequente de credenciais. Para nuvem, invalide sessões associadas quando o provedor permitir e revise políticas de função vinculadas a workloads de CI.
No médio prazo, controles de prevenção precisam tratar workflows como código sensível. Exija revisão obrigatória para qualquer alteração em .github/workflows, bloqueie execução automática de workflows alterados por identidades não confiáveis, use regras de ramificação para impedir push direto em ramos protegidos e monitore padrões de Base64 executável em arquivos de automação. Em ecossistemas npm, a orientação citada para migrar para Trusted Publishing reduz dependência de tokens de publicação persistentes. A invalidação de tokens granulares com escrita que contornavam 2FA reduz credenciais já coletadas, mas não substitui revisão de pipelines, remoção de segredos estáticos e isolamento de permissões por ambiente.
- Desabilitar workflows suspeitos e revisar todos os commits de CI/CD recebidos na janela de 18 de maio de 2026.
- Revogar e recriar PATs, deploy keys, chaves SSH, tokens de registro, credenciais de nuvem e arquivos de conta de serviço acessíveis aos runners.
- Definir permissões mínimas para
GITHUB_TOKENe exigir revisão obrigatória para alterações em.github/workflows. - Investigar runners que executaram payloads, incluindo caches, artefatos, logs, variáveis de ambiente e conexões de saída.
- Adotar publicação confiável quando disponível e reduzir uso de tokens persistentes com acesso de escrita em registros de pacotes.
0 Comentários