O malware foi assinado pela Red Hat
Esta semana, código que rouba credenciais chegou a programadores com o nome da Red Hat. A ameaça não veio de fora do seu círculo de confiança — veio de dentro dele. Não consegue auditar-se para fora disto. O que pode fazer é manter as suas credenciais fora de alcance.
Esta semana, código assinado pela Red Hat tentou roubar as suas credenciais.
Atacantes entraram na conta de um programador da Red Hat e publicaram versões adulteradas de pacotes oficiais da Red Hat. Assim que uma máquina instalava um deles, código oculto era executado automaticamente e ia buscar tudo o que encontrasse de valioso — chaves de cloud, tokens de acesso, inícios de sessão, tudo o que abre uma porta. Depois usava o que roubava para se propagar.
Repare no formato disto. A Red Hat não foi o alvo — você foi. O nome deles, a conta de confiança deles, o pipeline de instalação que já usou mil vezes sem pensar: isso não foi o dano colateral. Foi a arma. O ataque não se esgueirou para lá do seu círculo de confiança. Entrou pela porta da frente com um crachá que você próprio emitiu. É isto que torna os ataques à cadeia de fornecimento diferentes de tudo o resto — o perigo não é um estranho que consegue bloquear, é o fornecedor em que já decidiu confiar, a entregar o payload por si. E isto foi a Red Hat: uma das empresas mais maduras em segurança que existem, com revisão real e orçamento real. O código malicioso saiu na mesma com o nome deles.
Por isso aqui está a conclusão que não consegue evitar: se a Red Hat não consegue garantir que o que instala deles está limpo, ninguém consegue. Nem o seu framework, nem o seu fornecedor de CI, nem a dependência três níveis abaixo que nunca leu. Vai acabar por executar código que não escreveu e que não conseguiu auditar por completo. Isso não é uma falha de processo — é o que construir sobre o software de outras pessoas é.
Continue a fazer análises. Continue a fixar versões. Continue a auditar. Tudo isso vale a pena fazer — apenas não dependa disso, porque esta semana nada teria ajudado: o malware chegou pré-confiado. A questão real não é como manter o código mau lá fora. É esta: quando o código mau corre na sua máquina, protegeu os seus segredos?
Para quase toda a gente, a resposta honesta é não. Repare no que este ataque apanhou — variáveis de ambiente, tokens em ficheiros, e depois foi ter com os gestores de segredos na cloud e pediu-lhes o conteúdo. É assim que as credenciais vivem em 2026: empilhadas num só sítio, ao alcance de tudo o que esteja a correr. Uma má instalação não leva um segredo. Leva todos eles, e depois propaga-se.
A solução é parar de guardar as suas credenciais onde o seu código as pode apanhar. Mantenha-as à distância de um braço.
É essa a ideia por trás do funcionamento do Clavitor. Os seus segredos não vivem no seu ambiente; nada espera num ficheiro .env para ser lido. Um programa — ou um agente de IA — nunca detém a credencial. Obtém a capacidade de a usar, obtida de fresco no instante em que é necessária — nunca armazenada, nunca em cache — a partir de uma das nossas 21 localizações em seis continentes, para que a cópia mais próxima esteja sempre a milissegundos de distância, limitada ao único segredo que lhe foi concedido, com cada acesso registado. Quando um script de instalação malicioso tateia à procura de chaves, encontra uma sala vazia.
E assumimos que uma credencial acaba por ser apanhada, por isso o que um agente transporta é quase inútil se for roubado. Funciona apenas a partir da máquina à qual foi emitida — levem-na e executem-na a partir dos próprios servidores do atacante, e é recusada. Tem limite de taxa e é vigiada: alguns segredos por minuto, para que não consiga aspirar o seu cofre, e no momento em que ultrapassa o seu punhado habitual dispara um alerta e bloqueia. A estratégia inteira de um worm — apanhar tudo depressa, usar em todo o lado — bate numa parede.
Sem promessas de imunidade: se uma credencial está em uso ativo no instante em que o malware corre, essa pode ser apanhada — nenhuma arquitetura reescreve a física. Mas é esse o ponto. O ataque à Red Hat foi devastador porque uma instalação podia esvaziar um armazém inteiro de segredos e transformá-lo em arma. À distância de um braço, mais uma credencial presa a uma máquina e limitada a um fio de água, transforma "levaram tudo e propagaram-se" em "podem ter apanhado uma chave em trânsito, e não funcionou em mais lado nenhum". É essa a distância entre uma catástrofe e uma nota de rodapé.
O malware foi assinado pela Red Hat. Não vai conseguir auditar-se para fora disto. Assuma que o código entra — e certifique-se de que, quando entra, os seus segredos não estão ali à espera dele.
(Seguido publicamente como "Miasma", uma variante da família Shai-Hulud de worms npm de auto-propagação. Os artigos técnicos valem o seu tempo; este post é sobre a parte que não muda de um para o outro.)
Fontes: