Hack Alerta

Ataques usam PuTTY para movimento lateral e exfiltração — artefatos úteis

Relatórios recentes mostram que adversários têm abusado do cliente SSH PuTTY (plink/pscp) para movimento lateral e exfiltração de dados, enquanto deixam artefatos persistentes no registro do Windows (HKCU\\Software\\SimonTatham\\PuTTY\\SshHostKeys). Especialistas recomendam caça ativa desses artefatos, rotação de chaves SSH, whitelisting de binários e correlação com telemetria de rede para distinguir uso legítimo de atividade maliciosa.

Respostas a incidentes recentes mostram que adversários vêm abusando do cliente SSH PuTTY para pivôs laterais e extração de dados, deixando rastros persistentes no registro do Windows que podem ajudar a reconstruir cadeias de intrusão.

Introdução curta

O uso malicioso de ferramentas legítimas para 'living off the land' aumenta o desafio para detecção. Relatórios recentes detalham como variantes de PuTTY (plink, pscp) e builds trojanizados foram empregadas para movimentação lateral e exfiltração, enquanto atacantes tentam limpar traços em disco.

Descoberta e artefatos relevantes

Investigadores apontaram que, apesar de limpeza agressiva de arquivos e logs, o cliente PuTTY grava chaves de host SSH no registro do usuário em HKCU\Software\SimonTatham\PuTTY\SshHostKeys. Essas entradas contêm endereços-alvo, portas e impressões digitais — informações valiosas para correlação com telemetria de rede e logs de autenticação.

Vetor e uso tático

  • Inicialmente, agentes exploram métodos tradicionais de intrusão (malware inicial, credenciais comprometidas, spear‑phishing) para ganhar foothold em um sistema administrativo.
  • Uma vez no ambiente, atacantes usam plink.exe ou pscp.exe para criar túneis SSH, executar comandos remotos ou copiar arquivos diretamente para servidores controlados.
  • Campanhas documentadas incluem variantes com PuTTY trojanizado entregue via downloads envenenados por SEO que instalavam backdoors (referidos como Oyster em relatórios).

Evidências, detecção e limites

As descobertas recomendam focar em três frentes de detecção:

  • hunting em entradas do registro (SshHostKeys) para identificar hosts e portas incomuns;
  • correlação entre criação/execução de processos PuTTY e tráfego SSH para destinos não padrão ou horários atípicos;
  • análise de artefatos de ferramentas DFIR como Velociraptor para consultas rápidas sobre SshHostKeys e histórico de conexões.

Limitações: a presença de chaves no registro não diferencia uso legítimo de uso malicioso — é necessária correlação com outros sinais (fluxos, horários, contas usadas). Além disso, versões legítimas e builds trojanizados podem compartilhar nomes de arquivos idênticos, exigindo análise de hashes e da cadeia de certificação dos binários.

Medidas práticas para defenders

  • Mapear e autorizar hosts que usam PuTTY; bloquear execuções fora de lista branca via EDR/APP control;
  • rotacionar chaves SSH e eliminar chaves antigas em endpoints e servidores;
  • monitorar uso de portas SSH não padronizadas e alertar sobre túneis de saída para destinos externos;
  • implantar detecções baseadas em comportamento (execuções de plink/pscp seguidas de grandes transferências) em telemetria de rede;
  • inspecionar binários PuTTY em endpoints para identificar versões trojanizadas e comparar assinaturas/hashes com repositórios oficiais.

Implicações para resposta a incidentes

Em casos onde atacantes limpam logs e removem artefatos em disco, o registro do usuário pode oferecer um ponto de ancoragem para reconstruir o itinerário do invasor. Equipes de IR devem priorizar a preservação dessas chaves registradas e capturar fluxo de rede histórico antes que dados sejam rotacionados ou perdidos.

Observações finais

O abuso de ferramentas administrativas legítimas como PuTTY sublinha a necessidade de controles que vão além da simples assinatura de malware: políticas de whitelisting, visibilidade de telemetria e capacidade de caça ativa (hunting) são essenciais para identificar operações que tentam se misturar ao uso normal da TI. Quando detalhes técnicos adicionais estiverem disponíveis sobre campanhas específicas (IoCs, hashes), esses indicadores devem ser incorporados a regras de detecção e listas de bloqueio autorizadas.


Baseado em publicação original de Cyber Security News
Publicado pela Redação Hack Alerta com base em fontes externas citadas e monitoramento editorial do Hack Alerta. Para decisões técnicas, operacionais ou jurídicas, confirme sempre os detalhes na fonte original.