A maioria das equipas de segurança instala um EDR, instala um proxy e passa à ordem do dia. Contra o malware da cadeia de abastecimento, nenhum deles oferece uma proteção significativa, uma vez que foram concebidos para resolver um problema diferente.
O malware tradicional costuma infiltrar-se num computador, enquanto o malware da cadeia de abastecimento é convidado a entrar. O programador executa npm install, e o código malicioso é executado com todos os direitos de acesso. Essa inversão compromete ambas as ferramentas ao nível do design.
Por que é que o EDR não deteta malware
O EDR monitoriza os processos em busca de comportamentos suspeitos: chamadas de sistema invulgares, relações pai-filho inesperadas, assinaturas maliciosas conhecidas. A pergunta que se coloca é: «Este processo está a comportar-se como malware?»
O problema é que o malware da cadeia de abastecimento é executado em ambientes de execução confiáveis, realizando tarefas que esses ambientes realizam diariamente. Um script pós-instalação que lê ficheiros `.env` e envia o conteúdo por POST a um atacante parece idêntico a uma ferramenta de compilação que recupera credenciais para implementar código. Ambos são node ou python ler ficheiros e efetuar chamadas HTTP. As chamadas de sistema e as chamadas de rede são idênticas. O EDR não dispõe de qualquer contexto que indique que uma é legítima e a outra não.
Em março de 2026, os atacantes comprometeram a conta npm do principal mantenedor do axios, um pacote com cerca de 100 milhões de downloads semanais. Não alteraram o código-fonte. Adicionaram uma nova dependência cuja única função era um script pós-instalação que descarregava um RAT multiplataforma e se autoeliminava. Para um monitor de processos, isto era indistinguível do npm install a fazer o seu trabalho. Resolve uma dependência, executa um hook e faz um pedido HTTP.
Dois meses depois, três versões do durabletask, um pacote Python do ecossistema Azure da Microsoft, foram alvo de um ataque de backdoor. O texto tinha cerca de dez linhas __init__.py. O código obtém um ficheiro e executa-o num subprocesso, ignorando as exceções. Na segunda fase, foram recolhidas credenciais da AWS, Azure, GCP, Kubernetes e Vault, tendo-se depois propagado para outras instâncias através do SSM e para outros pods via kubectl exec, utilizando as credenciais da própria vítima, acedendo às APIs na nuvem da própria vítima. Em máquinas com configurações regionais israelitas ou iranianas, uma execução aleatória em cada seis executava o comando «rm -rf /*». Sem binários externos, sem destinos anómalos. O EDR não dispõe de um modelo para o caso em que o próprio pacote constitui a ameaça.
ataques à Supply chain camada são tão perigosos porque a carga maliciosa se apresenta como um comportamento normal. Não há anomalias para detetar, porque o objetivo é misturar-se no ruído ou, neste caso, ser o próprio ruído.
Por que é que os proxies não o detetam
Um proxy no caminho do tráfego pode interceptar o download de pacotes e compará-los com pacotes conhecidos como maliciosos. Em teoria, isso funciona. O problema é a parte do «no caminho do tráfego».
Os proxies remotos e corporativos são controlos opcionais nas máquinas dos próprios programadores. Os programadores trabalham a partir de casa, em cafés ou através da rede Wi-Fi de hotéis. Instalam ferramentas que contornam as definições de proxy do sistema. O VS Code gere os seus próprios downloads de extensões. O npm, o pip e o cargo têm os seus próprios clientes HTTP. Muitas ferramentas de linha de comandos e ambientes de execução de linguagens ignoram HTTP_PROXY por completo, a menos que seja explicitamente configurado. E quando uma ferramenta deixa de funcionar devido ao proxy, os programadores desativam o proxy, corrigem a ferramenta e esquecem-se de o reativar.
Casos como estes acontecem todos os dias. Um programador instala uma extensão do VS Code comprometida às 23h a partir do seu computador pessoal. Um executor de CI descarrega uma dependência maliciosa fora do perímetro da rede corporativa. Nenhuma dessas instalações passa pelo proxy. A verificação nunca é executada. A verificação que deveria ter detetado o problema simplesmente não existia.
O que realmente funciona
Tanto o EDR como os proxies resolvem problemas reais relacionados com as ameaças para as quais foram concebidos e continuam a ser valiosos. Simplesmente não abrangem a superfície de ataque da cadeia de abastecimento específica dos programadores.
Essa superfície precisa de algo que resida na própria máquina, que compreenda o que os pacotes estão a fazer durante a instalação e que esteja sempre presente, independentemente da configuração de rede. Criámos Aikido Protection precisamente para isso. Descubra neste blogue como várias organizações estão a utilizar o Device Protection para proteger as máquinas dos programadores.
Se quiser ter uma visão mais completa do que as ferramentas tradicionais para terminais não conseguem detetar nos computadores dos programadores, a versão MDM deste problema é abordada neste artigo.
