O malware KeyDrift transforma os controladores Cisco SD-WAN em coletores de chaves de encriptação

Os atacantes utilizaram uma vulnerabilidade de severidade máxima no Cisco Catalyst SD-WAN para instalar um implante feito à medida nos sistemas que orquestram a rede alargada de uma organização. O malware, identificado como KeyDrift, não rouba documentos nem credenciais. Rouba as chaves criptográficas que encriptam o tráfego entre sedes e guarda-as para mais tarde.

O que aconteceu

A porta de entrada é a CVE-2026-20127, um contorno de autenticação no plano de controlo do Catalyst SD-WAN com pontuação CVSS 10.0. Um atacante remoto não autenticado consegue saltar o início de sessão e obter privilégios administrativos no Controller (antigo vSmart), no Manager (antigo vManage) e no Validator (antigo vBond). Num Controller, o atacante entra numa conta interna de privilégios elevados que não é root, mas que tem permissões mais do que suficientes para instalar software.

A Cisco publicou correções em fevereiro de 2026 e alargou o aviso ao Validator a 16 de junho. O fabricante reconhece uma exploração limitada em ambiente real. As intrusões KeyDrift agora documentadas são descritas como históricas, e a análise pública não indica quando ocorreram nem se alguma chave recolhida chegou a sair das redes afetadas.

Como funciona o KeyDrift

Numa implementação Catalyst SD-WAN, cada router de fronteira gera periodicamente uma chave AES para o seu próprio tráfego e envia-a ao Controller, que a distribui pelos restantes routers. O processo que gere estas sessões de controlo encriptadas chama-se vdaemon. O KeyDrift vive dentro dele.

O implante tem duas peças principais:

• PolyFlame, o módulo central, é injetado em cada processo vdaemon em execução e corre inteiramente em memória. Pode funcionar como uma shell de comandos ligeira que executa comandos e lê ou escreve ficheiros, ou como um relé que reencaminha as ordens do operador para outras máquinas. Recebe instruções dentro do tráfego de controlo SD-WAN normal, e as amostras analisadas não continham qualquer servidor de comando fixado no código, o que dificulta a deteção ao nível da rede.
• LittleFilch liga-se ao vdaemon num Controller comprometido e lê as mensagens de controlo depois de desencriptadas. Para uma lista predefinida de routers de fronteira, extrai o endereço IP de cada um e um valor de 32 bytes avaliado como o material de chave AES-256 que o Controller distribui. Encripta o que recolhe com RSA, grava-o em disco e pode enviá-lo por UDP para um endereço lido de um ficheiro de configuração, que apaga assim que o lê.

A persistência é conseguida através da manipulação dos scripts de serviço runit que os equipamentos usam para arrancar os seus daemons. Numa variante, o script que lança o serviço SSH executa primeiro um carregador chamado conf_sshd, que regista os IDs de processo do vdaemon e os entrega a um injetor, rsshd, que carrega o PolyFlame em cada processo. Num Validator comprometido, um serviço falso chamado aaamgr executa um carregador empacotado que desencripta e arranca o PolyFlame. O componente aaamgr verdadeiro é um pacote Python e nunca corre como serviço compilado, pelo que a simples presença desse diretório é um indicador forte. Os operadores copiaram ainda as datas e permissões de ficheiros legítimos para os seus próprios ficheiros, para passarem despercebidos.

Quem está por trás

A atividade é seguida como UAT-11473. Os alvos conhecidos incluem serviços espaciais e de satélite, tecnologia de defesa e aeroespacial e organizações de investigação em políticas públicas. A sua infraestrutura sobrepõe-se consideravelmente à Silent Train, uma rede de dispositivos comprometidos de pequenos escritórios, escritórios domésticos e IoT que o grupo Volt Typhoon, ligado à China, tem usado para esconder as suas operações. As agências norte-americanas atribuíram publicamente o Volt Typhoon ao Estado chinês em 2024.

Essa ligação merece uma ressalva. Assenta em infraestrutura partilhada, não em ferramentas partilhadas, e ninguém afirmou que o UAT-11473 e o Volt Typhoon são o mesmo grupo. É também distinta de um cluster de exploração anterior, UAT-8616, associado a esta vulnerabilidade desde pelo menos 2023. Além disso, há relatos de que o próprio Volt Typhoon já explorava a CVE-2026-20127 no final de 2025 e continuou depois da divulgação de fevereiro, embora essa atividade não tenha sido associada ao KeyDrift.

Porque é importante

Os controladores SD-WAN são a âncora de confiança de todo o overlay. Quem detiver as chaves que eles distribuem consegue desencriptar e, potencialmente, repetir ou adulterar o tráfego entre cada sucursal, centro de dados e ponto de acesso à cloud da rede. Como as chaves são recolhidas de mensagens de controlo já desencriptadas em memória, não há ruído de exploit na rede depois de o implante estar instalado. E como o KeyDrift guarda as chaves "para mais tarde", um comprometimento descoberto hoje pode ter exposto tráfego capturado há meses.

A vulnerabilidade afeta mais do que os equipamentos locais. As implementações SD-WAN alojadas pela Cisco na cloud, incluindo os ambientes Managed e FedRAMP, estão abrangidas, embora a Cisco já tenha aplicado aí restrições de acesso.

O que fazer

1. Atualize para uma versão corrigida. Não existe solução alternativa.

Os ramos 20.11, 20.13, 20.14 e 20.16, bem como qualquer versão anterior a 20.9, chegaram ao fim da manutenção de software, pelo que é necessário saltar de ramo.

2. Restrinja as portas 22 e 830 nos componentes de controlo aos endereços IP dos controladores e sistemas de gestão conhecidos até conseguir atualizar. A Cisco validou esta medida em laboratório; teste-a na sua própria rede. Lembre-se de que bloquear portas nada faz contra um implante já instalado.

3. Procure o KeyDrift. Não foram publicados hashes, IPs nem domínios, pelo que a caça assenta em ficheiros e comportamento:

• o script run do runit em /etc/sv/sshd/ modificado para chamar conf_sshd;
• um diretório /etc/sv/aaamgr/ e um binário aaamgrd num Validator;
• conf_sshd, rsshd, libdssl.so (PolyFlame) e libcommon.so (LittleFilch);
• /tmp/system-vdaemon, /var/tmp/vdaemon.bin e /var/tmp/vdaemon.conf.

Desconfie das datas destes artefactos, uma vez que o grupo costuma falsificá-las.

4. Verifique a exploração da própria vulnerabilidade. Analise o /var/log/auth.log à procura de entradas "Accepted publickey for vmanage-admin" vindas de IPs de origem inesperados. Execute request admin-tech em cada componente de controlo e volte a analisar o resultado com a função Check Bug Applicability para o bug CSCws52722 antes de abrir um pedido de suporte.

5. Ative a cobertura IDS. As regras Snort 2 de 67387 a 67416 e as regras Snort 3 de 7:44 a 7:73 detetam as ligações de comando e controlo do KeyDrift; as regras 65938 e 65958 cobrem a vulnerabilidade. As novas regras Snort 2 vêm desativadas por omissão, por isso ative-as.

6. Planeie a expulsão, não apenas a correção. O guia de remediação da Cisco avisa que explorações já presentes podem sobreviver a uma atualização. Se encontrar qualquer indicador, inicie a resposta a incidentes, siga o guia de hardening do Catalyst SD-WAN e pondere seriamente a abordagem que a CISA impôs às agências federais norte-americanas em fevereiro: reinstale o Manager, o Controller e o Validator a partir de imagens limpas e corrigidas e migre os routers de fronteira para as novas instâncias. Rodar as chaves entre sedes é a hipótese prudente, já que todo o propósito do implante é guardar cópias delas.

Vulnerabilidades como esta costumam viver em equipamentos que ninguém analisa porque são "equipamento de rede" e não servidores. O nosso serviço de análise de vulnerabilidades inventaria as interfaces de gestão expostas pelos planos de controlo SD-WAN, VPN e firewall e assinala versões sem correção e portas de gestão acessíveis antes que um atacante com um exploit funcional as encontre primeiro.