Ransomware no Windows Server: Investigar pelo Event Viewer

Índice

• 1. A ordem de investigação
• 2. Confirmar a auditoria activa (e o que faltou)
• 3. Os 4688 da janela: quem correu o quê
• 4. Reconstruir a cadeia de processos
• 5. Por onde entrou: 4624, 4625 e tipos de logon
• 6. Persistência e cobertura: 7045, 4698, 4720, 1102 e 4104
• 7. Mapear a intrusão de ponta a ponta
• Veredicto

1. A ordem de investigação

O erro de quem entra no Event Viewer às pressas é filtrar «por Event ID» sem janela temporal e perder-se em milhares de linhas. A ordem que funciona:

1. Fecha o intervalo: o LastWrite mais antigo dos ficheiros encriptados marca o início da encriptação e o mais recente o fim — a janela que interessa são os minutos antes do primeiro.
2. Puxa os 4688 da janela (e os pais): um encriptador não aparece do ar — alguém (ou uma sessão) o lançou.
3. Sobe até à entrada: os 4624 anteriores revelam o logon que originou essa sessão — tipo de logon, máquina remota (SourceIpAddress), conta.
4. Nos registos de sistema/persistência: serviços, tarefas agendadas, utilizadores criados, apagamentos do log — o que veio depois e o que o atacante tentou esconder.

2. Confirmar a auditoria activa (e o que faltou)

Antes de filtrar: confirmar o que o servidor estava a auditar — e a primeira constatação é dura: o 4688 não vem activo por omissão. A subcategoria «Audit Process Creation» nas instalações de série está desactivada («Not Configured») e, sem ela, o histórico não tem 4688 nenhum. Confirma o estado real:

Se devolver "Desativado", o «quem correu o quê» fica sem prova — reporta o gap no relatório e apoia-te nos 4624/4625 (Logon/Logoff vem activo por omissão) e nas provas de rede/Sysmon que existirem.

auditpol /get /subcategory:"Process Creation"
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled

Mesmo com o 4688 activo, o CommandLine só é gravado com uma política adicional («Include command line in process creation events», Windows 10 1809+/Server 2019+). Se o valor lê-se 0x0 (ou a chave não existe), o 4688 mostra quem criou o processo e qual é — sem os argumentos. Para o próximo incidente (e para o servidor pós-reconstrução) activa-o via GPO/no registo:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable

Nota para o relatório: sem CommandLine, o 4688 não te diz os argumentos com que o encriptador correu (flags de modo silent, listas de exclusão). Os que seguem o mesmo caminho depois de ti ficam com a prova completa — é a primeira recomendação pós-limpeza.

3. Os 4688 da janela: quem correu o quê

O PowerShell puxa os 4688 da janela com os campos relevantes:

$inicio = Get-Date "2026-10-22 00:30:00"
$fim    = Get-Date "2026-10-22 04:00:00"
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=$inicio; EndTime=$fim } -MaxEvents 300 |
  Select-Object TimeCreated,
    @{n='Utilizador';e={$_.Properties[2].Value + '\' + $_.Properties[1].Value}},
    @{n='NovoProcesso';e={$_.Properties[5].Value}},
    @{n='PID';e={$_.Properties[4].Value}},
    @{n='LinhadeComandos';e={$_.Properties[8].Value}},
    @{n='Pai';e={$_.Properties[13].Value}} |
  Format-Table -AutoSize

Como ler esta tabela: NovoProcesso é o exe que arrancou, Pai é quem o lançou, e o Utilizador é a conta em que correu. Um ransomware assinala-se à distância: powershell.exe/cmd.exe com argumentos suspeitos, um exe num caminho de escrita ao vivo (Downloads, Temp, partilhas), vssadmin.exe delete shadows /all ou wbadmin delete catalog — o preparativo clássico para apagar backups locais antes da encriptação.

4. Reconstruir a cadeia de processos

O 4688 dá o PID novo e o PID do pai — a correlação entre ProcessId (pai) e os NewProcessId dos seguintes liga a árvore. O fragmento seguinte, corre depois de guardares os eventos numa variável:

$evs = Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=$inicio; EndTime=$fim }
# índice: NewProcessId → evento; procura: ParentProcessId → quem criou
$index = @{}
foreach ($e in $evs) { $index[$e.Properties[4].Value] = $e }
function Get-Chain($ev) {
  $out = @(); $cur = $ev
  while ($cur) {
    $out += $cur.Properties[5].Value
    $parentPid = $cur.Properties[7].Value      # ProcessId do pai (hex)
    $cur = $index[$parentPid]                  # o pai é um NewProcessId anterior
  }
  $out; }
Get-Chain ($evs | Where-Object { $_.Properties[5].Value -match 'cript' })[0]

Cadeias típicas que esta reconstrução revela: Winword.exe → cmd.exe → powershell.exe → ransom.exe (documento com macros, aberto por um utilizador com acesso de partilha), psexesvc.exe → cmd.exe → ransom.exe (lateral interno), wsmprovhost.exe → powershell.exe (WinRM remoto). A conta em cada elo muda — um servidor de ficheiros acedido pelo utilizador via rede tem o 4624 do tipo 3 a dizer-te a máquina de origem.

5. Por onde entrou: 4624, 4625 e tipos de logon

Com o encriptador identificado, o SubjectLogonId (campo 3 do 4688) é a chave: puxa os 4624 anteriores com o mesmo LogonId e vês a sessão que o lançou — tipo de logon, conta e SourceIpAddress:

Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4624; StartTime=$inicio.AddDays(-7); EndTime=$fim } |
  Where-Object { $_.Properties[7].Value -eq '0x4a5af0' } |
  Select-Object TimeCreated,
    @{n='Tipo';e={$_.Properties[8].Value}},
    @{n='Conta';e={$_.Properties[5].Value}},
    @{n='Origem';e={$_.Properties[18].Value + ':' + $_.Properties[19].Value}} |
  Format-Table -AutoSize

Os tipos de logon que vês num servidor (a tabela completa está na documentação do 4624):

6. Persistência e cobertura: 7045, 4698, 4720, 1102 e 4104

Depois do momento zero, o atacante deixa camadas. Cada uma tem evento próprio:

Nota: o 4698 e o 5140/5145 dependem de subcategorias de auditoria próprias (Object Access), que também não vêm activas por omissão — confirma com auditpol /get /category:"Object Access".

O 4104 vale ouro: desde o PowerShell 5.0 ficam gravados os script blocks que o motor considera suspeitos (nível Warning) mesmo sem política, e com a GPO «Turn on PowerShell Script Block Logging» ficam todos (nível Verbose) — inclui o loader do ransomware, muitas vezes ofuscado com -enc ou Base64. No PowerShell 7 o log passa a PowerShellCore/Operational.

Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-PowerShell/Operational'; Id=4104; StartTime=$inicio; EndTime=$fim } |
  Select-Object TimeCreated, @{n='ScriptBlock';e={$_.Properties[2].Value}} | Format-List

7. Mapear a intrusão de ponta a ponta

Com tudo reunido, o relatório de incidente num servidor típico sai assim (exemplo de uma intrusão por RDP com força bruta):

• Entrada: 4624 tipo 10 às 03:12 — conta administrador, origem 203.0.113.99. Antes disso, tentativas de 4625 do mesmo IP desde as 01:41. Leitura: RDP exposto à internet + password fraca.
• Reconhecimento: cmd.exe /c whoami && net user, wmic — minutos após o logon.
• Execução: powershell.exe -w hidden -enc SQBFAFc... (o 4104 mostra o script descarregado de um endereço externo).
• Preparação: vssadmin.exe delete shadows /all /quiet às 03:47. Fase de impacto a preparar.
• Corrupção: ransom.exe correu às 03:49 — a extensão nova nos ficheiros começa aqui.
• Cobertura: 1102 às 04:02 — o registo de auditoria foi limpo.

Cada linha sai dos comandos das secções anteriores — num cenário hipotético, nada é dedução: o tipo de logon é do 4624, os comandos dos 4688/4104, os momentos dos TimeCreated, a conta do campo Utilizador do 4688.

Veredicto

O Event Viewer de um Windows Server responde às três perguntas do dia após o ransomware — desde que a auditoria esteja activa: o 4624/4625 vem activo por omissão, o 4688 e o CommandLine precisam de GPO: quem (conta e LogonId), com que processo (a cadeia 4688), e por onde (4624/4625 + tipo de logon + IP de origem). O que não faz: telemetria da rede, conteúdo dos ficheiros, e provas quando o atacante limpa o log. Para um ambiente de produção a sério, as duas camadas que valem o investimento são o CommandLine nos 4688 e o Script Block Logging — e ambas activadas por GPO ANTES de precisares, não depois. No dia seguinte, o teu relatório de Incidente sai destes comandos, e a correcção vem daqui: fechar o RDP à internet, 2FA nas sessões remotas, e cópias de segurança testadas em isolamento — a leitura que os artigos de ransomware e de 3-2-1 já te dão.

Artigos Relacionados

• Ransomware: Protecção e Recuperação com Backups 3-2-1
• Checklist de Hardening para Servidores Linux (2026)
• Honeypots e Canary Tokens: Detectar Intrusos

Fontes Oficiais

• 4688(S): A new process has been created — Windows auditing (Microsoft Learn)
• 4624(S): An account was successfully logged on — tipos de logon (Microsoft Learn)
• about_Logging — Script Block Logging e o evento 4104 (Microsoft Learn)
• about_Logging_Windows — Script Block Logging no PowerShell 7 (Microsoft Learn)
• PowerShell the Blue Team — 4104 Warning automático sem política (devblogs Microsoft)