PowerShell para auditar logs de segurança no Windows

Imagine que alguém passou as últimas 48 horas tentando adivinhar a senha de um usuário no seu servidor Windows. Sem monitoramento, você nunca saberia — até o dia em que eles acertassem. O Windows registra tudo isso no Security Event Log. O problema é que o Event Viewer é lento, cheio de cliques e impossível de automatizar. O PowerShell resolve isso em uma linha.

Get-WinEvent: o cmdlet certo para eventos de segurança

Existe o Get-EventLog (legado) e o Get-WinEvent (moderno). Use sempre o Get-WinEvent — ele é significativamente mais rápido em logs grandes, suporta filtragem por hash direto na consulta (sem trazer tudo pra memória primeiro) e não está sendo mais desenvolvido no PowerShell 7+. O Get-EventLog sequer existe no PowerShell Core rodando em Linux.

Para ler o Security Log você precisa de um terminal elevado (Executar como Administrador). Se tentar sem privilégios, vai receber um erro de acesso negado — não é bug, é comportamento esperado de um log que guarda dados sensíveis de autenticação.

# Verificar os últimos 50 eventos do log de segurança
Get-WinEvent -LogName Security -MaxEvents 50 | Select-Object TimeCreated, Id, Message

Os Event IDs que você precisa conhecer

O Windows tem centenas de IDs de evento, mas para auditar segurança no dia a dia, uns poucos cobrem a grande maioria dos cenários críticos:

• 4624 — Logon bem-sucedido (qualquer login na máquina)
• 4625 — Falha de logon (senha errada, conta bloqueada, usuário inválido)
• 4634 / 4647 — Logoff (sessão encerrada)
• 4648 — Logon com credenciais explícitas (pass-the-hash, runas)
• 4688 — Novo processo criado (requer auditoria de criação de processo ativa)
• 4698 — Tarefa agendada criada (vetor clássico de persistência de malware)
• 4720 — Conta de usuário criada
• 4732 — Membro adicionado a grupo privilegiado (ex: Administradores)
• 4776 — Autenticação NTLM local (relevante para detectar ataques laterais)

Se você gerencia Active Directory, adicione também o 4768 (requisição de Kerberos TGT) e 4771 (falha de pré-autenticação Kerberos) à sua lista de observação.

Detectar logins falhos nas últimas 24 horas

Este é o caso de uso mais comum. Qualquer servidor exposto à internet acumula tentativas de login constantemente — especialmente na porta 3389 (RDP) e em contas de serviço com senhas fracas.

# Listar falhas de logon das últimas 24 horas
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    [PSCustomObject]@{
        Hora    = $_.TimeCreated
        Usuario = $_.Properties[5].Value
        IP      = $_.Properties[19].Value
        Motivo  = $_.Properties[8].Value
    }
} | Sort-Object Hora -Descending

O acesso via $_.Properties[n].Value extrai campos específicos do evento sem precisar parsear texto. As propriedades do evento 4625 são fixas: índice 5 é o nome de usuário alvo, 19 é o endereço IP de origem, 8 é o sub-status de falha (código que indica se a conta não existe, senha errada, conta bloqueada etc.).

Identificar brute force: agrupar por IP atacante

Uma ou duas falhas podem ser erro humano. Cinquenta falhas do mesmo IP em dez minutos são brute force. O PowerShell agrupa isso em segundos:

# Top 10 IPs com mais falhas de logon (últimos 7 dias)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-7)
} | ForEach-Object {
    $_.Properties[19].Value
} | Where-Object { $_ -ne '-' -and $_ -ne '' } |
    Group-Object |
    Sort-Object Count -Descending |
    Select-Object -First 10 Count, Name

Um IP aparecendo com centenas de tentativas é candidato imediato para bloqueio no firewall ou no Windows Firewall via New-NetFirewallRule. O caso do ataque à Trellix e de várias outras operações de ransomware começaram com brute force em contas expostas sem proteção adequada.

Verificar tarefas agendadas criadas recentemente (persistência)

Criar uma tarefa agendada é um dos mecanismos de persistência mais usados por malware — e o Windows loga cada criação com o evento 4698. Se você não tem criado tarefas agendadas manualmente, qualquer ocorrência desse ID merece atenção:

# Tarefas agendadas criadas nas últimas 48 horas
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4698
    StartTime = (Get-Date).AddHours(-48)
} | Select-Object TimeCreated, Message

Exportar relatório de auditoria para CSV

Para enviar por e-mail ou arquivar, basta canalizar o resultado para Export-Csv. Isso funciona com qualquer um dos scripts acima — troque o final da pipeline:

# Exportar falhas de logon para CSV
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-7)
} | ForEach-Object {
    [PSCustomObject]@{
        Hora    = $_.TimeCreated
        Usuario = $_.Properties[5].Value
        IP      = $_.Properties[19].Value
    }
} | Export-Csv -Path ".\falhas-logon-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation -Encoding UTF8

O nome do arquivo inclui a data automaticamente via Get-Date -Format 'yyyyMMdd'. Se você nunca usou isso, o post PowerShell para iniciantes cobre os fundamentos de pipeline e formatação de objetos que tornam esses scripts possíveis.

Ativar auditoria de criação de processo (evento 4688)

Por padrão, o Windows não registra quais processos foram criados — o que deixa um ponto cego enorme para detectar execução de ferramentas maliciosas. Para ativar via Group Policy localmente:

# Verificar política atual de auditoria de processos
auditpol /get /subcategory:"Process Creation"

# Ativar auditoria de criação de processo (requer admin)
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable

Depois de ativar, você pode combinar isso com filtros no evento 4688 para detectar execução de powershell.exe com argumentos codificados em base64 — padrão clássico de execução de payload ofuscado. Para ambientes corporativos, a recomendação é gerenciar isso via GPO centralizado e integrar os logs num SIEM, mas mesmo localmente já é um passo significativo de visibilidade.

Conclusão

Event logs existem em todo ambiente Windows, mas ficam invisíveis sem ferramentas para consultá-los de forma eficiente. Com Get-WinEvent e filtros por hash, você tira relatórios de segurança em segundos — sem terceirizar isso para um produto caro. Se você gerencia servidores Windows e ainda não tem esse tipo de verificação no seu checklist semanal, vale começar pelos eventos 4625 e 4698: são os dois que mais frequentemente revelam algo que não deveria estar acontecendo. Se quiser camadas extras de monitoramento de rede além dos logs locais, o NextDNS com filtragem de DNS criptografado é um complemento prático para ambientes domésticos e pequenas empresas. Passou por alguma situação onde os logs ajudaram a identificar um problema? Conta nos comentários.