PowerShell para DFIR — Parte 2: Encontrando Persistência no Windows

Remover um serviço malicioso, excluir uma tarefa agendada ou apagar um executável suspeito pode parecer o fim de um incidente. Na maioria das vezes, é apenas o fim do mecanismo mais óbvio. Adversários com algum nível de maturidade raramente dependem de um único ponto de reentrada — eles constroem redundância, exatamente como uma equipe de infraestrutura constrói alta disponibilidade.

Essa redundância pode assumir várias formas: um segundo mecanismo de persistência como fallback caso o primeiro seja descoberto, credenciais válidas coletadas durante o acesso inicial, uma ferramenta de acesso remoto legítima reconfigurada para uso indevido, ou até um pequeno processo “watchdog” cuja única função é recriar o artefato principal caso ele seja removido. Cada um desses elementos, isoladamente, pode passar despercebido durante uma triagem apressada.

Durante resposta a incidentes, encontrar um mecanismo de persistência deve aumentar a suspeita de que existem outros — não reduzi-la.

Nesta segunda parte da série sobre PowerShell aplicado à segurança, mudamos de perspectiva: em vez de técnicas ofensivas, o foco é DFIR (Digital Forensics and Incident Response) — como usar PowerShell e ferramentas do ecossistema open source para caçar, validar e documentar persistência em hosts Windows, com disciplina forense e sem atalhos que comprometam a investigação.

O que é persistência

Em termos técnicos, persistência é qualquer mecanismo que garante que um código continue sendo executado — ou volte a ser executado — mesmo após eventos que normalmente interromperiam essa execução: reinicialização do sistema, logoff do usuário, encerramento do processo, troca de usuário ou reinício de serviços. No MITRE ATT&CK, esse conjunto de técnicas está organizado sob a tática TA0003 — Persistence.

Para um adversário, investir em persistência é uma decisão racional: o acesso inicial a um ambiente costuma exigir esforço — phishing bem-sucedido, exploração de uma vulnerabilidade, uso de credenciais vazadas — e nenhum operador quer repetir esse esforço porque um processo foi encerrado ou uma máquina reiniciada durante uma janela de manutenção.

Mapa de persistência no Windows

O Windows oferece uma quantidade notável de superfícies onde código pode ser configurado para execução automática. Antes de qualquer ferramenta, vale internalizar esse mapa — é ele que orienta onde uma triagem manual deve olhar quando as ferramentas automatizadas não estão disponíveis.

BootExecute: um artefato pouco explorado

Um dos locais menos conhecidos — e por isso mesmo interessante do ponto de vista forense — é o valor BootExecute, dentro de:

HKLMSYSTEMCurrentControlSetControlSession Manager

Esse valor é processado pelo Session Manager Subsystem (smss.exe) em um estágio muito inicial do boot, antes mesmo da inicialização completa do subsistema Win32 — momento em que a maioria das soluções de EDR ainda não está totalmente operante. Por padrão, o valor contém apenas autocheck autochk *, responsável por disparar a verificação de disco quando necessário. Qualquer entrada adicional nesse valor é, no mínimo, incomum e merece investigação imediata.

A consulta é simples e inteiramente passiva:

Get-ItemProperty `
  "HKLM:SYSTEMCurrentControlSetControlSession Manager" `
  -Name BootExecute

Ao interpretar o resultado, compare o conteúdo do valor com o padrão esperado (autocheck autochk *). Qualquer executável, script ou caminho adicional ali é motivo para escalar a investigação — esse é exatamente o tipo de artefato que ferramentas de triagem manual costumam ignorar, mas que scanners de persistência dedicados, como veremos adiante, incluem em sua varredura.

Antes de caçar persistência: conheça o normal

Nenhuma ferramenta de detecção de persistência substitui o conhecimento do ambiente. Toda organização tem uma golden image — ou deveria ter — com um conjunto conhecido de software corporativo, drivers, agente de EDR, ferramentas administrativas e tarefas agendadas legítimas. Sem essa baseline, um analista gasta tempo desproporcional investigando falsos positivos: o agente de backup que roda como serviço, o atualizador de driver que se registra no Run key, o agente de RMM que a própria TI instalou.

O princípio central aqui é simples de enunciar e fácil de esquecer sob pressão:

Existência não implica malícia. Todo achado de persistência precisa ser avaliado no contexto do ambiente antes de virar uma conclusão.

PersistenceSniper

O PersistenceSniper é um módulo PowerShell criado para varrer um host local em busca de mecanismos de persistência conhecidos, contextualizando cada achado com informações que aceleram a triagem — em vez de apenas listar caminhos, ele indica a técnica associada e uma descrição do que aquele artefato representa. No momento desta publicação, o projeto documenta cerca de 60 técnicas de persistência cobertas, organizadas na página de detecções do próprio repositório.

O que o PersistenceSniper analisa

Entre as categorias cobertas estão:

• Services e seus caminhos de imagem (image paths)
• Scheduled Tasks e suas ações/triggers
• Registry Run e RunOnce keys (HKLM e HKCU)
• Chaves relacionadas ao Winlogon
• Itens de Startup (pasta e Registry)
• WMI Event Subscriptions
• AppInit DLLs
• O valor BootExecute discutido acima

Instalação e execução

A forma oficial de instalação, via PowerShell Gallery, é:

Install-Module PersistenceSniper -Scope CurrentUser
Import-Module PersistenceSniper

E a varredura completa é disparada por um único cmdlet:

Find-AllPersistence -Verbose

O trecho abaixo é uma recriação ilustrativa — não uma captura real — de como uma linha de resultado costuma se apresentar, simplificada para fins didáticos:

# Exemplo ilustrativo de saída (dados fictícios de laboratório)
Technique          : Run Key
Path                : HKCUSoftwareMicrosoftWindowsCurrentVersionRun
Value               : UpdaterSvc
Signature           : Not signed
User                : LABanalyst
Description         : Suspicious binary launched via user Run key

Como ler os resultados

Campo	Significado	O que verificar
Technique	Categoria de persistência identificada	Se é uma técnica de alto risco (BootExecute, WMI) ou de baixo risco relativo (Run key comum)
Path / Registry Location	Onde o artefato foi encontrado	Se o caminho é conhecido/documentado no ambiente
Value / Command	O comando, binário ou script referenciado	Localização do arquivo, argumentos, se está em diretório gravável por usuário comum
Signature	Se o binário referenciado está assinado	Ausência de assinatura em software que deveria ser assinado
User	Contexto de usuário associado ao artefato	Se o usuário faz sentido para aquele tipo de configuração

Nem tudo que é persistente é malicioso

É comum que uma primeira execução do PersistenceSniper em um host corporativo retorne dezenas de resultados — a grande maioria legítima. Exemplos recorrentes de falso positivo:

• Agentes de EDR e antivírus registrados como serviço
• Clientes VPN corporativos
• Drivers e atualizadores de hardware (GPU, chipset)
• Software de backup e sincronização
• Ferramentas de monitoramento de infraestrutura

É exatamente por isso que a etapa de baseline, discutida anteriormente, não é opcional — sem ela, o volume de ruído torna a ferramenta pouco produtiva.

Quando usar o PersistenceSniper

O ponto forte da ferramenta é a triagem local rápida: um host recém-isolado, uma primeira passagem de um analista de resposta a incidentes, ou a validação de que a remediação realmente eliminou os artefatos identificados anteriormente. Não é, por desenho, uma ferramenta de coleta distribuída.

Trawler

O Trawler parte de uma filosofia diferente. Enquanto o PersistenceSniper tende a ser abrangente e explicativo, o Trawler foi desenhado para reduzir ruído e destacar candidatos que realmente merecem atenção de um analista — usando allowlists internas específicas por versão de Windows (10, Server 2012/2016/2019/2022) para suprimir configurações padrão conhecidas.

A execução básica, a partir do script principal:

.trawler.ps1

O projeto expõe parâmetros adicionais relevantes para um fluxo real de DFIR, entre eles -scanoptions, -quiet, -outpath, -hashmode e -snapshot — este último permite gerar um “retrato” de um host limpo (golden image) para servir de allowlist específica do ambiente, reduzindo ainda mais o ruído em execuções futuras.

Forense offline: o diferencial do Trawler

Um recurso particularmente valioso para DFIR é o parâmetro -drivetarget, que permite apontar o Trawler para uma imagem forense montada em vez do host ao vivo:

# Exemplo: imagem forense montada como F:
.trawler.ps1 -drivetarget "F:"

Nesse modo, o Trawler carrega os hives de Registry relevantes diretamente da imagem — HKLMSOFTWARE, HKLMSYSTEM, além dos NTUSER.DAT e USRCLASS.DAT de cada perfil de usuário — e reavalia os caminhos de artefatos baseados em arquivo em relação à raiz montada. Isso é essencial em cenários onde o host não pode ou não deve ser ligado novamente (preservação de evidência, host já desligado, disco extraído para análise).

Vale registrar uma limitação importante do próprio projeto: ao operar em modo -drivetarget, o Trawler não tem como inspecionar processos em execução, conexões de rede, DLLs “phantom”, consumidores WMI, jobs do BITS ou realizar parsing de certificados — todos esses dependem de um sistema ativo. Isso reforça um ponto recorrente em DFIR: análise offline e análise ao vivo são complementares, não substitutas uma da outra.

Limitações do Trawler

O próprio README do projeto é direto sobre um risco inerente a qualquer allowlist: um adversário com conhecimento do ambiente pode deliberadamente mimetizar processos e nomes padrão do sistema operacional para escapar da detecção automatizada. Allowlisting reduz ruído, mas também é uma superfície que pode gerar falsos negativos se o adversário conhece as regras.

“Nenhum achado” não significa “host limpo”. Significa apenas que, dentro do escopo verificado por aquela ferramenta e configuração, nada ultrapassou o limiar de suspeita.

Kansa

O Kansa resolve um problema diferente dos dois anteriores. Ele não é, em essência, um scanner de persistência — é um framework de coleta distribuída para resposta a incidentes, que usa PowerShell Remoting (WinRM) para executar módulos de coleta em múltiplos hosts simultaneamente e consolidar os resultados para análise.

Isso o coloca mais próximo de frameworks de distributed incident response e hunting at scale do que de um scanner local como os dois anteriores. Onde PersistenceSniper e Trawler respondem “o que existe neste host”, o Kansa responde “onde mais, no ambiente inteiro, esse mesmo indicador aparece”.

Arquitetura

A execução básica aponta um ou mais hosts-alvo e um diretório de módulos:

.kansa.ps1 -Target $env:COMPUTERNAME -ModulePath .Modules -Verbose

Modules.conf e coleta seletiva

O Kansa organiza sua coleta em módulos independentes dentro do diretório Modules, cada um responsável por um artefato específico (processos, conexões de rede, serviços, Prefetch, etc.). O arquivo Modules.conf permite selecionar quais módulos executar e em que ordem — útil tanto para acelerar uma coleta de triagem (poucos módulos, resposta rápida) quanto para uma coleta forense completa (todos os módulos disponíveis). Como a ferramenta evolui com contribuições da comunidade, vale sempre conferir a lista de módulos disponível no repositório antes de planejar uma coleta em escala.

Artefatos úteis para hunting de persistência

• Prefetch — evidência de execução de binários, mesmo já removidos
• Cache de DNS — domínios recentemente resolvidos pelo host
• Conexões de rede (netstat) — comunicação ativa ou recente
• Aplicativos recentes / itens executados
• Scheduled Tasks e Services, coletados em todos os hosts do escopo
• Chaves de Registry relevantes (Run, Winlogon)
• Logs de eventos do Windows

Hunting em escala

O fluxo típico de uso do Kansa em um incidente real segue um padrão simples: um host comprometido é identificado, um indicador é extraído dele (um hash, um caminho de arquivo, uma chave de Registry, um nome de tarefa agendada), e esse indicador é então buscado nos demais hosts do ambiente — dezenas, centenas ou milhares de endpoints — para determinar o real alcance do comprometimento. É essa capacidade de escalar horizontalmente que diferencia o Kansa de uma ferramenta de triagem local.

Comparando as três ferramentas

Ferramenta	Escopo	Melhor uso	Vantagem	Limitação
PersistenceSniper	Host local	Triagem rápida, primeira passagem	Resultados contextualizados, ~60 técnicas cobertas	Pode gerar volume alto de ruído sem baseline
Trawler	Local ou imagem offline	Hunting com allowlist, análise forense de imagem	Menor ruído, suporte real a imagem montada	Modo offline não cobre processos/rede/WMI ativos
Kansa	Frota (múltiplos hosts)	Coleta distribuída, correlação em escala	Centraliza dados de toda a frota via WinRM	Exige WinRM e infraestrutura de coleta configurada

Fluxo prático de triagem

Independentemente da ferramenta usada para encontrar o artefato inicial, um fluxo disciplinado de triagem evita erros comuns:

1. Identificar o artefato (caminho, chave, tarefa, serviço)
2. Preservar a evidência antes de qualquer alteração
3. Registrar o caminho/chave/task/serviço completo
4. Capturar timestamps de criação e modificação
5. Calcular o hash do binário envolvido
6. Validar a assinatura digital
7. Investigar o processo pai (ancestralidade)
8. Verificar conexões de rede associadas
9. Correlacionar o indicador no EDR/SIEM
10. Buscar o mesmo indicador no restante do ambiente

Hashing

Get-FileHash "C:Labsuspicious.exe" -Algorithm SHA256

Assinatura digital

Get-AuthenticodeSignature "C:Labsuspicious.exe" |
    Select-Object SignerCertificate, Status, StatusMessage

Status indica se a assinatura é válida, e StatusMessage detalha o motivo quando não é — expirada, revogada, emitida por uma CA não confiável ou simplesmente ausente. Binários legítimos da Microsoft praticamente sempre estarão assinados; a ausência de assinatura em um binário que deveria ser assinado é um sinal de atenção, não uma prova definitiva.

Processos e ancestralidade

Get-CimInstance Win32_Process |
    Select-Object ProcessId, ParentProcessId, Name, CommandLine

Cruzar ProcessId com ParentProcessId permite reconstruir a árvore de execução. Um processo de sistema (como svchost.exe) tendo como pai um processo que normalmente não deveria gerá-lo é um padrão clássico de investigação.

Conexões de rede

Get-NetTCPConnection | Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess

O campo OwningProcess permite correlacionar diretamente uma conexão de rede com o processo identificado na etapa anterior.

Consultas defensivas por artefato

As consultas abaixo são todas somente-leitura — nenhuma cria ou modifica um mecanismo de persistência. São o tipo de comando que compõe a checklist manual de um analista quando ferramentas automatizadas não estão disponíveis ou precisam ser validadas manualmente.

Scheduled Tasks

Get-ScheduledTask | Select-Object TaskPath, TaskName, State
Get-ScheduledTask -TaskName "NomeDaTarefa" | Select-Object -ExpandProperty Actions
Get-ScheduledTask -TaskName "NomeDaTarefa" | Select-Object -ExpandProperty Triggers
Get-ScheduledTask -TaskName "NomeDaTarefa" | Select-Object -ExpandProperty Principal

Actions revela o que a tarefa executa, Triggers revela quando, e Principal revela sob qual conta e nível de privilégio. Os três juntos formam o quadro completo — uma action apontando para um interpretador de script combinada com um principal privilegiado e um autor não reconhecido justifica investigação imediata.

Services

Get-CimInstance Win32_Service |
    Select-Object Name, StartMode, State, PathName

Indicadores que merecem atenção no campo PathName: binário em diretório incomum (pasta temporária, diretório de perfil de usuário), caminho gravável por usuários não administrativos, nome de serviço propositalmente semelhante a um serviço legítimo do Windows (troca sutil de caracteres) e serviços configurados para rodar sob contas de usuário em vez de contas de sistema quando isso não é o padrão esperado.

Registry Run Keys

Get-ItemProperty `
  "HKCU:SoftwareMicrosoftWindowsCurrentVersionRun"

Get-ItemProperty `
  "HKLM:SoftwareMicrosoftWindowsCurrentVersionRun"

Existem variantes menos conhecidas que também merecem checagem manual: RunOnce, a versão Wow6432Node em sistemas 64-bit (usada por aplicações 32-bit) e as chaves equivalentes sob cada hive NTUSER.DAT de outros perfis de usuário no host.

WMI Event Subscriptions

A persistência via WMI é montada a partir de três componentes: um __EventFilter (a condição que dispara a execução), um CommandLineEventConsumer (o que será executado) e um __FilterToConsumerBinding (a ligação entre os dois). É uma técnica historicamente associada a operações mais sofisticadas, justamente por não deixar arquivo em disco nem entrada óbvia no Registry.

Get-CimInstance -Namespace rootsubscription -ClassName __EventFilter
Get-CimInstance -Namespace rootsubscription -ClassName CommandLineEventConsumer
Get-CimInstance -Namespace rootsubscription -ClassName __FilterToConsumerBinding

Na maioria dos hosts sem software de gerenciamento avançado, esse namespace deveria estar vazio ou conter apenas entradas conhecidas de produtos corporativos (alguns EDRs e ferramentas de gerenciamento usam WMI subscriptions legitimamente) — qualquer entrada não reconhecida é prioridade de investigação.

Winlogon

Dois valores dentro de HKLM:SoftwareMicrosoftWindows NTCurrentVersionWinlogon merecem atenção redobrada: Shell (normalmente explorer.exe) e Userinit (normalmente C:Windowssystem32userinit.exe,). Qualquer desvio desses valores padrão — um executável adicional anexado, um caminho totalmente diferente — indica um mecanismo de persistência que é executado no início de toda sessão de logon.

Startup Folders

Os atalhos colocados nas pastas de inicialização (a do usuário atual e a global “All Users”) são executados automaticamente no logon. É um dos mecanismos mais simples de configurar — e, por isso, um dos primeiros lugares que vale checar manualmente:

Get-ChildItem "$env:APPDATAMicrosoftWindowsStart MenuProgramsStartup"
Get-ChildItem "$env:ProgramDataMicrosoftWindowsStart MenuProgramsStartUp"

Persistência que não parece malware

Um dos aspectos mais desafiadores do hunting moderno é que boa parte da persistência observada em incidentes reais não é malware no sentido tradicional — é abuso de ferramentas legítimas já presentes ou instaladas pelo próprio adversário com aparência de administração de TI.

• AnyDesk, TeamViewer, ScreenConnect, RustDesk e outras ferramentas de acesso remoto
• Soluções de RMM (Remote Monitoring and Management) usadas por MSPs

Nenhuma dessas ferramentas é maliciosa por definição — são amplamente usadas de forma legítima. O que diferencia uso legítimo de abuso é o contexto: a ferramenta foi instalada pela TI conhecida? Existe um ticket ou aprovação associada? A conta usada para instalar é uma conta administrativa legítima? Um agente RMM instalado fora do processo de mudança padrão da organização é, por si só, um forte indicador de persistência.

Credenciais como mecanismo de reentrada

Remover todo malware e todo artefato de persistência de um host não fecha um incidente se o adversário ainda possui credenciais válidas coletadas durante o acesso inicial. Isso inclui contas administrativas locais, contas de domínio, contas de serviço, credenciais de VPN e RDP, e — cada vez mais comum — credenciais de provedores de nuvem. Esse tema não é o foco técnico deste artigo, mas precisa estar presente em qualquer runbook de remediação: persistência de acesso via credenciais é tão real quanto persistência via artefato técnico.

Watchdogs

Em nível conceitual, um “watchdog” de persistência é qualquer componente cuja única função é garantir a sobrevivência de outro componente — um processo que monitora se o payload principal ainda está rodando e o reinicia se não estiver, um serviço que recria um arquivo removido, ou uma tarefa agendada que restaura um binário apagado. É por isso que remover apenas o artefato mais visível, sem investigar se existe um watchdog associado, é uma causa comum de reinfecção aparentemente “misteriosa” logo após a remediação.

Correlacionando persistência com telemetria

Achados de uma varredura de persistência ganham muito mais valor quando correlacionados com telemetria de SIEM e EDR. Eventos conceitualmente relevantes para essa correlação incluem: criação de serviço, registro de tarefa agendada, modificação de chaves de Registry sensíveis, atividade de WMI, criação de processo com linha de comando completa, e os logs de PowerShell descritos na primeira parte desta série (Script Block Logging, Module Logging).

Mapeamento MITRE ATT&CK

Os principais mecanismos discutidos neste artigo mapeiam para técnicas bem documentadas da tática TA0003 — Persistence:

• T1547 — Boot or Logon Autostart Execution (inclui T1547.001, Registry Run Keys / Startup Folder)
• T1053 — Scheduled Task/Job (inclui T1053.005, Scheduled Task)
• T1543 — Create or Modify System Process (inclui T1543.003, Windows Service)
• T1546.003 — Event Triggered Execution: WMI Event Subscription

Vale registrar que Registry Run Keys / Startup Folder e Scheduled Task/Job estão entre as técnicas de persistência mais observadas em campanhas reais documentadas pelo MITRE — o que reforça por que ambas recebem tanta atenção neste artigo e nas três ferramentas discutidas.

Hardening: reduzindo a superfície de persistência

Detecção e resposta são reativas por natureza. A redução estrutural da superfície de persistência é o que diminui a frequência e o impacto dos incidentes ao longo do tempo:

• Least privilege — contas do dia a dia sem privilégio administrativo local
• Windows LAPS — rotação automática de senhas administrativas locais, discutido em detalhe abaixo
• WDAC / AppLocker — controle de aplicação restringindo o que pode executar
• EDR com Tamper Protection habilitado
• PowerShell logging — Script Block Logging e Module Logging habilitados via GPO
• Auditoria de criação de tarefas e serviços (Event ID 4698 e 4697/7045)
• Monitoramento de Registry nas chaves discutidas neste artigo
• Application allowlisting em hosts críticos e servidores
• Restrição de ferramentas RMM não aprovadas via política de aplicação

Windows LAPS

O Windows LAPS (Local Administrator Password Solution) rotaciona automaticamente a senha da conta administrativa local de cada máquina, armazenando o valor atual de forma segura no Active Directory ou Entra ID. Isso é particularmente relevante para persistência: sem rotação, uma senha administrativa local comprometida em um host pode ser reutilizada indefinidamente em qualquer outra máquina que compartilhe a mesma senha — um padrão de configuração ainda comum em ambientes legados.

Monitoramento de Registry prioritário

Se apenas um pequeno conjunto de chaves puder receber monitoramento ativo com alertas, priorize: BootExecute, WinlogonShell e WinlogonUserinit, e as chaves Run/RunOnce tanto em HKLM quanto em HKCU. São os locais de maior retorno por esforço de monitoramento, dado o histórico de abuso documentado.

Sequência de remediação

1. Isolar o host da rede
2. Preservar evidência (memória, disco, artefatos identificados)
3. Investigar a extensão do comprometimento
4. Remover os mecanismos de persistência identificados
5. Rotacionar todas as credenciais potencialmente expostas
6. Realizar hunting lateral com os indicadores coletados
7. Validar ausência de persistência secundária
8. Reintegrar o host ao ambiente
9. Manter monitoramento reforçado por um período definido

A rotação de credenciais (passo 5) é frequentemente subestimada: remover malware sem trocar as credenciais expostas durante o acesso inicial deixa a porta de reentrada mais simples — e mais silenciosa — completamente aberta.

Verificação pós-remediação

Antes de considerar um host reintegrado ao ambiente, reexecute a mesma bateria de verificações usada na triagem inicial — dessa vez esperando resultado negativo:

• Nova varredura com PersistenceSniper
• Nova varredura com Trawler
• Coleta via Kansa comparada com a baseline do ambiente
• Confirmação de detecção limpa no EDR
• Ausência de alertas relacionados no SIEM
• Revisão manual de Registry (Run, Winlogon, BootExecute)
• Revisão manual de Scheduled Tasks e Services
• Revisão do namespace WMI de subscriptions
• Inventário de ferramentas RMM instaladas
• Confirmação de rotação de todas as credenciais expostas

Persistência além do Windows

Vale um registro breve: persistência não é um problema exclusivo do Windows. Em ambientes Linux, os equivalentes conceituais mais comuns são unidades systemd maliciosas ou modificadas, entradas de cron/crontab, alterações em shell profiles (.bashrc, .profile) e processos watchdog análogos aos discutidos neste artigo. O raciocínio de triagem — baseline, contexto, correlação com telemetria — se transfere diretamente, mesmo que os artefatos técnicos específicos sejam outros.

Cheat sheet

Objetivo	PowerShell
Listar tarefas agendadas	Get-ScheduledTask
Listar serviços	Get-CimInstance Win32_Service
Consultar Run Keys	Get-ItemProperty HKCU:...Run
Consultar BootExecute	Get-ItemProperty ...Session Manager -Name BootExecute
Consultar WMI subscriptions	Get-CimInstance -Namespace rootsubscription ...
Calcular hash	Get-FileHash -Algorithm SHA256
Ver assinatura digital	Get-AuthenticodeSignature
Listar conexões de rede	Get-NetTCPConnection
Listar processos com ancestralidade	Get-CimInstance Win32_Process
Varredura local completa	Find-AllPersistence (PersistenceSniper)
Hunting com allowlist	.trawler.ps1
Coleta distribuída	.kansa.ps1 -Target ... -ModulePath ...

Checklist de hunting de persistência

Uma lista de verificação prática para uma triagem completa, combinando ferramentas automatizadas e revisão manual:

• Scheduled Tasks (automatizado + revisão manual de Actions/Triggers/Principal)
• Services (image path, conta de execução, modo de inicialização)
• Registry Run / RunOnce (HKLM e HKCU, incluindo Wow6432Node)
• Winlogon (Shell, Userinit)
• BootExecute
• Startup Folders (usuário e global)
• WMI Event Subscriptions (__EventFilter, Consumer, Binding)
• PowerShell Profiles
• AppInit DLLs
• Ferramentas de RMM e acesso remoto instaladas
• Contas locais e de domínio criadas ou modificadas recentemente
• Rotação de credenciais potencialmente expostas
• Hash e assinatura de todo binário suspeito identificado
• Ancestralidade de processos suspeitos
• Conexões de rede associadas aos processos suspeitos
• Correlação com EDR/SIEM
• Varredura com PersistenceSniper
• Varredura com Trawler
• Coleta e comparação via Kansa (se em escala)
• Nova execução de toda a checklist após remediação

Conclusão

Persistência raramente é um evento único — é, na maioria dos incidentes com adversário minimamente organizado, um sistema redundante de múltiplos mecanismos independentes. A ausência de achados em uma ferramenta automatizada não é prova de que um host está limpo; é apenas a confirmação de que, dentro do escopo verificado, nada ultrapassou o limiar configurado de suspeita.

PersistenceSniper, Trawler e Kansa cobrem necessidades diferentes e complementares — triagem local contextualizada, hunting com ruído reduzido e análise offline, e coleta distribuída em escala, respectivamente — mas nenhuma delas substitui a validação humana, o conhecimento da baseline do ambiente e a disciplina forense de preservar antes de remover. Remediação eficaz precisa ir além do artefato técnico: inclui rotação de credenciais e retroalimenta a detecção com cada achado, fechando o ciclo entre resposta a incidentes e postura defensiva de longo prazo.

Se você quer revisitar os fundamentos de PowerShell — objetos, pipeline e os cmdlets que também aparecem nas consultas defensivas deste artigo — o Null Trace publicou anteriormente PowerShell para Segurança Ofensiva — Parte 1: Fundamentos, primeiro artigo de uma série editorial distinta, focada em fundamentos e uso ofensivo autorizado, mas com boa sobreposição técnica com o que foi discutido aqui.