Hunting por Movimento Lateral (PSExec, WMI, RDP)

Nota 02 do Capítulo 08, "Técnicas de Hunting por TTPs", aplicando hipóteses e consultas à
tática de Movimento Lateral (TA0008). Continua a estrutura da nota 01 e dialoga com as notas
de logon e autenticação do capítulo 02, com TH.7, TH.8 e TH.9 do framework e com o TH.14,
dedicado à análise de autenticação e credenciais.

1. Contexto e Posicionamento na Biblioteca

O movimento lateral é o momento em que o adversário deixa de operar em uma única máquina e começa a percorrer a rede, usando credenciais roubadas e protocolos administrativos legítimos para alcançar ativos de maior valor. A tática é especialmente favorável ao hunting por duas razões estruturais. Primeira, todo salto lateral produz autenticação observável: logons de rede, logons interativos remotos e uso explícito de credenciais aparecem no log Security de origem e de destino. Segunda, os protocolos abusados, SMB, WMI, RDP e WinRM, têm padrões de uso corporativo previsíveis, e é justamente o desvio desses padrões, e não um IOC específico, que revela a atividade.

A nota organiza a caça em quatro movimentos: mapear técnicas e eventos, reconhecer as anomalias de fluxo de logon que caracterizam percursos anormais, executar consultas KQL por protocolo e correlacionar origens com múltiplos destinos, o padrão clássico de um adversário em reconhecimento interno ou em propagação. A análise fina de autenticação, com tipos de logon, pacotes de autenticação e contas, é aprofundada no TH.14, e esta nota fornece a camada operacional de consultas que materializa aquela técnica.

2. Técnicas de Movimento Lateral e Telemetria Associada

Cada protocolo abusado deixa combinação característica de eventos, e a tabela consolida os quatro mais usados em ambiente Windows, com o comportamento típico e os eventos que o revelam.

A leitura tática da tabela indica que PSExec é a técnica mais ruidosa, porque cria serviço visível nos eventos 7045 e 4697, enquanto WMI e WinRM são mais discretos, dependendo de telemetria de processo e de script block para se tornarem visíveis. RDP ocupa posição intermediária: o logon tipo 10 é registrado por padrão, mas a origem da conexão exige o log RemoteConnectionManager ou o campo IpAddress do 4624. Essa hierarquia de ruído orienta a priorização do caçador quando a telemetria é parcial.

3. Anomalias de Fluxo de Logon

O hunting de movimento lateral se apoia em fluxos anômalos de autenticação, não em hashes ou nomes de ferramenta. Os padrões que elevam prioridade são: logon de estação para estação, raro em frotas administradas onde usuários não acessam desktops de pares; conta administrativa autenticando em grande número de hosts em janela curta, sinal de varredura de credenciais ou de propagação; tipo de logon incoerente com o protocolo esperado, como tipo 10 vindo de subredes de servidores onde ninguém deveria abrir sessão RDP; uso de NTLM onde a política da rede prevê Kerberos, típico de ferramentas que passam hash ou de credenciais explícitas; e autenticações fora do horário ou sem precedentes para aquela conta na baseline do INS.5.

Outro sinal poderoso é a sequência, e não o evento isolado: 4648 seguido de 4624 tipo 3 na mesma origem indica tentativa de uso explícito de credenciais culminando em logon bem sucedido; 7045 no destino seguido de 4624 tipo 3 da mesma origem caracteriza PSExec completo; 4624 tipo 10 seguido de criação de usuário ou de modificação em minutos caracteriza operação administrativa não autorizada. O caçador deve tratar esses encadeamentos como hipóteses testáveis e documentá-las, pois são exatamente o que as detecções do capítulo 18 reproduzirão depois.

4. Consultas Práticas em KQL

4.1 PSExec e clones

A criação de serviço pelo par PSEXESVC é a assinatura mais estável, presente mesmo em variantes renomeadas que mantêm o sufixo do serviço.

Event
| where EventID == 7045 and Source startswith "Microsoft-Windows-"
| extend X = parse_xml(EventData).DataItem.EventData.Data
| extend ServiceName = tostring(X[0]["@text"]), ImagePath = tostring(X[1]["@text"])
| where ServiceName matches regex @"(?i)PSEXESVC" or ImagePath has_any ("PSEXESVC", "paexec", "remcom", "smbexec")
| project TimeGenerated, Computer, ServiceName, ImagePath

A telemetria de processo confirma a execução dos filhos do serviço, cujo pai é o binário de serviço no caminho administrativo do sistema.

Event
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| extend X = parse_xml(EventData).DataItem.EventData.Data
| extend Image = tostring(X[4]["@text"]), CommandLine = tostring(X[10]["@text"]),
         ParentImage = tostring(X[20]["@text"])
| where ParentImage has "PSEXESVC" or ParentImage has "paexec" or ParentImage has "remcom"
| project TimeGenerated, Computer, ParentImage, Image, CommandLine

4.2 WMI remoto

No destino, o provedor WMI aparece como pai de interpretadores, combinação que na rotina administrativa é rara, pois a gestão moderna prefere agentes e ferramentas de deploy dedicadas.

Event
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| extend X = parse_xml(EventData).DataItem.EventData.Data
| extend Image = tostring(X[4]["@text"]), CommandLine = tostring(X[10]["@text"]),
         ParentImage = tostring(X[20]["@text"])
| where ParentImage has "wmiprvse" and Image has_any ("cmd.exe", "powershell.exe", "rundll32.exe", "wscript.exe")
| project TimeGenerated, Computer, Image, CommandLine, ParentImage

O uso explícito de credenciais, típico de ferramentas que fornecem usuário e senha na linha de comando WMI, aparece como 4648 na máquina de origem e deve ser empilhado por conta e por janela.

SecurityEvent
| where EventID == 4648 and TimeGenerated > ago(7d)
| summarize ContasUsadas = dcount(TargetUserName), Destinos = dcount(Computer) by SubjectUserName, bin(TimeGenerated, 1h)
| where ContasUsadas >= 3 or Destinos >= 3

4.3 RDP

O logon tipo 10 traz a origem no campo IpAddress, o que permite construir diretamente a matriz de pares origem e destino. A camada de sessões do LocalSessionManager complementa com desconexões e reconexões, úteis para cronometrar quanto tempo o adversário permaneceu em sessão.

SecurityEvent
| where EventID == 4624 and LogonType == 10 and TimeGenerated > ago(7d)
| summarize Sessoes = count(), Contas = dcount(Account) by IpAddress, Computer, bin(TimeGenerated, 1h)
| where Sessoes >= 2 or Contas >= 2
| order by IpAddress asc, Sessoes desc

Event
| where Source == "Microsoft-Windows-TerminalServices-LocalSessionManager" and EventID in (21, 24, 25)
| extend X = tostring(parse_xml(EventData))
| extend Usuario = extract(@"<Data[^>]*>([^<]+)</Data>", 1, X)
| project TimeGenerated, Computer, EventID, Usuario

4.4 WinRM e PowerShell remoting

O WinRM executa comandos dentro de wsmprovhost, e a melhor telemetria complementar é o script block logging do PowerShell, evento 4104, que preserva o comando mesmo quando ofuscado em base64.

Event
| where EventID == 4104 and Source contains "PowerShell"
| where Message has_any ("Invoke-Command", "New-PSSession", "Enter-PSSession", "-EncodedCommand",
                         "Invoke-Mimikatz", "Get-ADUser", "[System.Convert]::FromBase64String")
| summarize Ocorrencias = count(), Hosts = dcount(Computer) by bin(TimeGenerated, 1h)
| where Hosts >= 3

SecurityEvent
| where EventID == 4624 and LogonType in (3, 8) and TimeGenerated > ago(24h)
| where AccountType == "User" and not(Account startswith "NT " or Account == "ANONYMOUS LOGON")
| summarize Logons = count(), Origens = dcount(IpAddress) by Account, Computer, bin(TimeGenerated, 1h)
| where Logons >= 3 or Origens >= 2

5. Correlação de Destino Múltiplo

A correlação de destino múltiplo é a técnica que transforma logons isolados em percursos. A consulta central agrega por conta e por origem o número de destinos distintos tocados em janela curta; contas administrativas de SCCM, Ansible ou gestão legítima ocupam posições estáveis e altas dessa distribuição, e o que interessa é a novidade: conta que historicamente não aparece na pilha do TH.8 e surge tocando dezenas de máquinas. A segunda camada empilha pares origem e destino, expondo arestas raras do grafo de autenticação, que em redes bem segmentadas são raras por construção.

SecurityEvent
| where EventID == 4624 and LogonType in (3, 10) and TimeGenerated > ago(24h)
| summarize Destinos = dcount(Computer), Logons = count() by Origem = IpAddress, Conta = Account
| where Destinos >= 10
| order by Destinos desc

SecurityEvent
| where EventID == 4624 and LogonType in (3, 10) and TimeGenerated > ago(7d)
| summarize Ocorrencias = count() by Origem = IpAddress, Destino = Computer
| where Ocorrencias <= 2
| order by Ocorrencias asc

A leitura combinada das duas consultas segue o padrão do TH.9: a primeira pergunta quem fala com muitos, a segunda quem fala com quem nunca falou. Pares raros de estações entre si, de contas de usuário comum tocando servidores e de subredes administrativas originando logon em estações são os três desvios que concentram a maior parte dos casos reais de movimento lateral.

6. Exemplo de Caça Completa

Cenário: uma conta de suporte usada apenas no SCCM aparece na consulta de destino múltiplo tocando 23 servidores em duas horas, sem correspondência na baseline. A primeira consulta de PSExec não retorna nada, descartando criação de serviço; a consulta de WMI retorna cinco execuções de powershell com pai wmiprvse em quatro desses servidores. O encadeamento temporal mostra 4648 na estação de origem pouco antes de cada salto, indicando uso de credenciais explícitas, e o script block logging revela comandos de enumeração e de cópia de arquivos para um compartilhamento.

A resposta segue o IR.x: contenção da conta, isolamento das cinco máquinas com spawn de WMI, varredura retrospectiva com o TH.7 pela combinação pai wmiprvse e filhos interpretadores em 90 dias, e revisão da política de credenciais administrativas. O caso vira detecção permanente no capítulo 18, a conta entra na pilha recorrente de destino múltiplo como referência conhecida e o TH.14 recebe o registro do padrão de abuso para as próximas revisões de política de autenticação.

7. Erros Comuns e Pontos de Atenção

• Caçar apenas o evento 7045 e concluir que não há movimento lateral: WMI, WinRM e RDP não criam serviços, e a ausência de PSEXESVC não prova nada além da ausência de PSExec.
• Ignorar que o campo Account do 4624 inclui contas de máquina terminadas em cifrão, que dominam o volume de logons tipo 3 e precisam ser filtradas antes de qualquer agregação por conta.
• Aplicar limiares de destino múltiplo iguais para toda a rede: servidores de aplicação e jump servers legitimamente falam com muitos destinos, e o limiar deve ser calibrado por população na baseline do INS.5.
• Confundir o evento 1149 com sessão concluída: ele registra tentativa de conexão do RemoteConnectionManager, e a sessão efetiva exige o 21 do LocalSessionManager ou o 4624 tipo 10.
• Esquecer o tipo de logon 8, NetworkCleartext, que alguns clientes WinRM antigos produzem e que raramente é legítimo em ambiente corporativo moderno.

8. Integração com o Restante da Biblioteca

A caça de movimento lateral consome as baselines de autenticação do INS.5 e do TH.2, usa o TH.14 como referência conceitual para tipos de logon e pacotes de autenticação, e alimenta o TH.9 com as arestas do grafo origem e destino. Os percursos confirmados alimentam o IR.x com a lista de máquinas tocadas, base para contenção proporcional, e as sequências validadas se convertem em detecções de encadeamento no capítulo 18, que são mais duráveis que alertas de evento único. A inteligência de infraestrutura do capítulo 05 adiciona a dimensão externa, comparando origens internas com endpoints de VPN e com dispositivos gerenciados.

Uma orientação operacional encerra a nota: a consulta de destino múltiplo é a de maior retorno da tática e deve entrar na rotina mensal, enquanto as consultas por protocolo rendem mais como caças dirigidas por hipótese após eventos de exposição de credenciais, como vazamentos, phishing com captura de senha ou desligamentos de funcionários com acesso privilegiado. Essa divisão entre rotina e dirigido espelha a estrutura de cadências do capítulo 07 e será reutilizada nas notas seguintes do capítulo.