Persistência encoberta em Linux: Velvet Ant modifica PAM e OpenSSH para capturar credenciais

Um ator ligado à China conhecido por pesquisadores como Velvet Ant levou a persistência de um novo nível: em vez de se esconder em software novo ou ferramentas próprias, modificou os próprios programas que decidem quem entra nos sistemas Linux. Segundo as análises públicas e a trajetória do grupo, o adversário chegou a substituir componentes críticos do sistema de autenticação — PAM e OpenSSH — com versões maliciosas que registravam credenciais e comandos, ou que aceitavam senhas ocultas; trabalho sigiloso que pode passar por administração legítima durante anos.

A técnica é duplamente perigosa: primeiro porque ataca o ponto mais confiável do host – o que valida identidades – e segundo porque o objetivo era, em muitos casos, redes isoladas sem acesso direto à Internet. Para chegar até lá os atacantes usaram sistemas expostos como ponte e ferramentas disfarçadas que retransmitiam ordens para o segmento “air-gapped”. Esse enfoque paciente e modular parece-se às campanhas prévias do mesmo ator, que usaram dispositivos de infraestrutura como F5 BIG‐IP ou switches Cisco NX‐OS como plataformas internas de comando e controle.

As implicações operacionais são claras: os procedimentos padrão de contenção, como fechar sessões ou forçar a mudança de palavras-passe, podem ser ineficazes se a peça que valida essas credenciais for comprometida. Resetear chaves sem antes verificar e limpar a cadeia de autenticação deixa uma porta aberta para que as novas credenciais sejam capturadas e exfiltradas.

Do ponto de vista defensivo, a primeira lição é mudar a vigilância para onde tradicionalmente não se olha. Monitoramento de integridade de arquivos Para os binários de login (por exemplo /usr/sbin/sshd e os módulos de PAM em /lib/security ou /lib64/security de acordo com a distribuição) deve estar na lista prioritária. Além de alertas em tempo real, convém implementar caça ativa: comparar hashes dos executáveis com cópias conhecidas e assinadas pelo fornecedor e verificar a integridade do pacote usando ferramentas do próprio gestor de pacotes (rpm -V, debsums ou outras alternativas de acordo com a distro).

As ações de remediação requerem cautela. Não substitua nem reinicie cegas um binário de autenticação na produção; uma cópia incorreta pode bloquear administradores e complicar a recuperação. O fluxo razoável é isolar a equipe, arrancar de um meio de resgate (live CD/USB) para obter um ambiente de confiança, verificar e substituir os binários com artefatos assinados ou construídos em um ambiente de CI seguro, e apenas então rotar credenciais e chaves. Probar qualquer substituição em laboratórios reprodutíveis antes de aplicar em produção reduz o risco de erros fatais.

A higiene complementar que reduz a janela de abuso inclui limitar ao mínimo os serviços e contas com privilégios de administração, forçar autenticação multifator para acessos críticos e preferir autenticação baseada em chaves e agentes com proteção de hardware quando possível. Também há que auditar e bloquear canais de retransmissão invulgares: revisar servidores Web expostos que possam atuar como ponte e monitorar conexões salientes inesperadas desde appliances de rede e balanceadores.

No caso específico das vulnerabilidades usadas anteriormente por este ator, os equipamentos devem assegurar a aplicação dos adesivos e mitigações recomendadas pelos fabricantes e pelas autoridades de segurança. As organizações podem consultar avisos e guias oficiais para confirmar a exposição da sua infraestrutura; recursos públicos como CISA ou relatórios de assinaturas de resposta a incidentes como Sygnia oferecem contexto técnico e passos de mitigação úteis. Para entender melhor os componentes atacados e como protegê-los, convém rever também as fontes originais do software como OpenSSH e Linux- PAM.

Finalmente, a lição estratégica é que a confiança por defeito na infraestrutura deve ser substituída por Verificação contínua. Componentes historicamente considerados estáveis e “sempre corretos” –balanceadores, switches, e especialmente o próprio login – são agora objetivos de persistência. A defesa eficaz exige a integração de controlos de integridade na supervisão cotidiana, políticas de recuperação que contemplem arranques de meios de confiança, e exercícios de caça de ameaças que verifiquem mudanças em artefatos críticos antes de assumir que um restabelecimento de credenciais fecha o incidente.