Hackers exploraram uma falha crítica do Cisco Catalyst SD-WAN (rede de longa distância definida por software), corrigida em fevereiro, para instalar um malware personalizado nos sistemas que controlam a rede SD-WAN de uma organização.
O malware, chamado KeyDrift, foi projetado para copiar as chaves que criptografam o tráfego entre sites e armazená-las para uso posterior, conforme informou a Cisco Talos em 28 de outubro. A Talos classifica os ataques como históricos, mas não especifica quando ocorreram nem se alguma chave foi enviada.
A falha é rastreada como CVE-2026-20127 (identificador de vulnerabilidades e exposições comuns) e tem pontuação CVSS de 10,0 (sistema de pontuação de severidade de vulnerabilidades, em escala de 0 a 10). Ela permite que um invasor remoto não autenticado contorne a autenticação e obtenha privilégios administrativos nesses sistemas de controle. Em um Controller, o invasor pode entrar como uma conta interna de alto privilégio que não é root.
Quando a Cisco divulgou a falha em fevereiro, a Talos passou a monitorar sua exploração como UAT-8616 (sigla da Talos para grupos de ameaça ainda não identificados), um conjunto de atividades que, segundo a empresa, remonta pelo menos a 2023.
Na troca de chaves tradicional da Cisco, cada roteador SD-WAN gera periodicamente uma chave AES (Padrão de Criptografia Avançada) para seu tráfego e a envia ao Catalyst SD-WAN Controller (antigo vSmart). O Controller repassa as chaves a outros roteadores. Um processo do Controller chamado vdaemon executa as conexões de controle criptografadas que transportam essas chaves.
Em um Controller comprometido, um componente do KeyDrift chamado LittleFilch se conecta ao vdaemon e lê as mensagens de controle depois de descriptografadas. Para uma lista predefinida de roteadores de borda, ele extrai seus endereços IP (Protocolo de Internet) e um campo de 32 bytes. A Talos avalia que esse campo é o material de chave AES-256 que o Controller repassa entre roteadores.
O LittleFilch criptografa o que coleta com RSA (algoritmo de criptografia de chave pública) e grava o resultado em um arquivo. Depois, pode enviar esses dados por UDP (Protocolo de Datagramas de Usuário) para um endereço listado em um arquivo de configurações, que ele apaga após a leitura. A Talos não conseguiu recuperar esse arquivo.
O grupo por trás do KeyDrift, que a Talos rastreia como UAT-11473, tem como alvos serviços espaciais e de satélite, tecnologias de defesa e aeroespaciais e pesquisa de políticas públicas.
A infraestrutura do grupo “se sobrepõe consideravelmente” à do Silent Train, afirma a Talos com alta confiança. Silent Train é o nome que o Black Lotus Labs, da Lumen, usa para uma rede de dispositivos invadidos de pequenos escritórios e residências (SOHO, sigla de small office/home office), além de dispositivos de IoT (Internet das Coisas) e dispositivos empresariais.
A Lumen afirma que o Volt Typhoon usou essa rede para ocultar sua atividade. A CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA), a NSA (Agência de Segurança Nacional) e o FBI (Polícia Federal dos EUA) afirmaram em 2024 que o Volt Typhoon é um grupo cibernético patrocinado pelo Estado chinês.
A Talos associa o UAT-11473 ao Volt Typhoon apenas pela sobreposição de infraestrutura. A empresa não afirma que os dois são o mesmo grupo nem explica como o UAT-11473 se relaciona com o UAT-8616, o conjunto de atividades que relatou em fevereiro.
Em separado, a Lumen afirmou em 28 de outubro que o Volt Typhoon explorava a CVE-2026-20127 desde o fim de 2025 e continuou a explorá-la depois que a Cisco divulgou a falha, em fevereiro. A Lumen não relaciona essa atividade ao KeyDrift.
Segundo a Talos, o KeyDrift começa principalmente por meio de scripts runit modificados, que os dispositivos Cisco SD-WAN usam para iniciar seus serviços. Em uma versão, o script do serviço SSH (Protocolo Seguro de Shell) inicia um script carregador, o conf_sshd, antes do servidor SSH real. O conf_sshd grava os IDs de processo do vdaemon em um arquivo, e uma ferramenta chamada rsshd injeta o módulo principal do KeyDrift, o PolyFlame, em cada um desses processos.
O PolyFlame roda na memória, dentro do vdaemon. Ele pode atuar como uma backdoor semelhante ao TinyShell, que executa comandos e lê e grava arquivos, ou como um relé que encaminha comandos entre seu servidor de comando e outras máquinas. Ele foi construído para aceitar comandos dentro do tráfego de controle do SD-WAN, e as amostras analisadas não continham nenhum endereço de servidor codificado diretamente no programa.
Em um Validator comprometido, antigo vBond, um falso serviço aaamgr em /etc/sv/aaamgr/ executa um carregador compactado, o aaamgrd, que descriptografa e executa o PolyFlame. O componente aaamgr real da Cisco é um pacote Python e não costuma rodar como serviço compilado.
Há também sinais de timestomping (adulteração de carimbos de data e hora): comandos executados pelo grupo copiaram os carimbos de data e hora e as permissões de arquivos existentes para os arquivos próprios do grupo.
Versões afetadas e correções
A falha CVE-2026-20127 afeta o Catalyst SD-WAN Controller (antigo vSmart), o Manager (antigo vManage) e o Validator (antigo vBond), independentemente da configuração. São afetados os sistemas locais, assim como as implantações em nuvem hospedadas pela Cisco, incluindo os ambientes Cisco Managed e FedRAMP (programa federal de autorização de segurança em nuvem dos EUA). A Cisco incluiu o Validator em seu aviso em 16 de junho.
A Cisco afirma estar ciente de exploração limitada da falha. Não há solução alternativa, e as primeiras versões corrigidas são:
Versões anteriores à 20.9 e as linhas 20.11, 20.13, 20.14 e 20.16 atingiram o fim do suporte de manutenção de software.
Até que possam atualizar, os clientes locais podem limitar o acesso às portas 22 e 830 aos endereços IP dos controllers conhecidos e de outros sistemas conhecidos. A Cisco afirma que essa medida funcionou em um ambiente de teste, mas que os clientes devem verificar seu desempenho em suas próprias redes. Essas proteções já estão em vigor nas implantações em nuvem hospedadas pela Cisco.
Bloquear as portas não remove o malware que já esteja em um dispositivo.
Como verificar a presença do KeyDrift
A Talos recomenda que as organizações instalem as correções da Cisco, sigam o guia de endurecimento de segurança do Catalyst SD-WAN da Cisco e fiquem atentas a sinais de atividade pós-comprometimento. Quem encontrar tais sinais deve iniciar a resposta a incidentes e pode pedir ajuda ao Centro de Assistência Técnica (TAC) da Cisco.
Essa orientação não diz se a atualização remove o KeyDrift de um dispositivo já comprometido nem se alguma chave deve ser substituída. O guia de correção da Cisco, publicado em fevereiro para essa falha, alerta que podem existir “explorações existentes que ainda estão em vigor” desde antes da atualização.
O KeyDrift usa os seguintes arquivos e locais, alguns citados apenas pelo nome:
- Arquivo: o script de execução em etc/sv/sshd/, modificado para iniciar o conf_sshd
- Diretório: /etc/sv/aaamgr/, um falso serviço em um Validator comprometido
- Arquivo: aaamgrd, o carregador compactado
- Arquivo: conf_sshd, o script carregador
- Arquivo: rsshd, o injetor
- Arquivo: libdssl.so, o PolyFlame
- Arquivo: libcommon.so, o LittleFilch
- Arquivo: /tmp/system-vdaemon, a lista de IDs de processo do vdaemon
- Arquivo: /var/tmp/vdaemon.bin, os registros criptografados do LittleFilch
- Arquivo: /var/tmp/vdaemon.conf, as configurações de envio do LittleFilch, apagadas após a leitura
O relatório da Talos não inclui uma lista de hashes de arquivos, endereços IP ou domínios relacionados ao KeyDrift.
Em 28 de outubro, a Talos publicou regras do Snort que procuram conexões de comando e controle (C2) de entrada do KeyDrift: as regras 67387 a 67416 para o Snort 2 e 7:44 a 7:73 para o Snort 3. As regras 65938 e 65958, já disponíveis, cobrem a própria CVE-2026-20127.
A atualização de regras de 28 de outubro lista as regras do Snort 2 como desativadas por padrão, por isso os usuários do conjunto pago Snort Subscriber precisam ativá-las. As regras do Snort 3 aparecem sem estado padrão definido.
Para verificar a exploração da própria falha, a Cisco recomenda procurar no arquivo /var/log/auth.log as entradas “Accepted publickey” para vmanage-admin vindas de endereços IP desconhecidos. Antes de abrir um chamado no TAC, os clientes devem executar request admin-tech em cada componente de controle. O guia de correção também recomenda analisar novamente esses arquivos admin-tech com o recurso Check Bug Applicability, na página Bug Search Tool, para o bug CSCws52722.
Para as agências civis federais dos EUA, a diretiva de emergência da CISA de 25 de fevereiro define o que fazer se for encontrado um comprometimento de conta root. As agências devem comunicar o caso à CISA, implantar novas instâncias de Manager, Controller e Validator a partir de imagens corrigidas e mover seus roteadores de borda para os novos sistemas.
