Persistencia em Windows: 10 Tecnicas Documentadas e suas Contramedidas

Persistencia nao e a parte glamourosa de um compromisso, mas e a que separa um adversario que perde acesso na primeira reinicializacao daquele que volta tres semanas depois quando o time esqueceu do alerta. Na Basilisk OffSec rodamos exercicios contra clientes em que mais de 70% das deteccoes que viraram caso real comecaram em mecanismos triviais: chaves Run, scheduled tasks com nomes engracadinhos, servicos com paths nao quotados. O objetivo deste catalogo nao e ensinar a esconder implantes, e sim documentar dez tecnicas reais que vemos toda semana e entregar queries KQL que o seu Defender XDR ou Sentinel pode rodar amanha de manha.

A primeira familia que importa cobrir e a das chaves de registro de execucao automatica. HKCU\Software\Microsoft\Windows\CurrentVersion\Run continua sendo o T1547.001 mais explorado em campanhas commodity, e nao porque os atacantes sao preguicosos, mas porque ele funciona em qualquer perfil sem precisar de privilegio. Uma query simples como DeviceRegistryEvents | where RegistryKey has "CurrentVersion\\Run" and InitiatingProcessFileName !in ("explorer.exe","msiexec.exe") ja pega 80% dos casos quando voce baseliner por hostname. Para entender o contexto ofensivo desses caminhos, vale revisitar Initial Access Simulado: Macros, LNK e ISO em Lab Windows 11 Isolado porque a maioria dos macros que vemos em lab termina escrevendo exatamente nessas chaves.

Scheduled Tasks (T1053.005) sao a segunda tecnica mais abusada e a mais subnotificada. O problema nao e detectar a criacao da task, e sim filtrar o ruido: um Windows 11 corporativo cria em media 40 tasks legitimas em update cycles. A query que tem nos servido melhor e DeviceProcessEvents | where FileName == "schtasks.exe" and ProcessCommandLine has_any ("/create","/change") | where InitiatingProcessParentFileName !in (~"msiexec.exe",~"trustedinstaller.exe") combinada com enriquecimento via Get-ScheduledTask filtrando Author vazio ou autor sem assinatura. Em paralelo, monitorar o evento 4698 no Security log e revisar TaskCache\Tree no registro pega tasks ocultas que nao aparecem no schtasks /query.

Servicos Windows (T1543.003) continuam sendo o vetor preferido quando o atacante ja tem SYSTEM. Aqui o foco do blue team deve estar em tres sinais: criacao de servico apontando para binario nao assinado, ImagePath em diretorios mundo-gravavel como ProgramData ou Public, e o classico unquoted service path. Uma boa caca comeca com DeviceEvents | where ActionType == "ServiceInstalled" | where FolderPath !startswith "C:\\Windows\\" and FolderPath !startswith "C:\\Program Files". Para nao confundir com instalacoes legitimas, faca join com a tabela de certificados e descarte tudo que tem signer corporativo conhecido. Esse padrao ecoa o que cobrimos em Hunting de Living-off-the-Land Binaries no Windows com KQL sobre baseline-driven detection.

WMI Event Subscription (T1546.003) e onde a coisa fica seria. E silenciosa, sobrevive a reinicializacao e raramente aparece em playbooks juniores. A receita: monitorar __EventFilter, __EventConsumer e __FilterToConsumerBinding na classe root\subscription. No Defender, DeviceEvents | where ActionType == "WmiBindEventFilterToConsumer" funciona, mas em ambientes sem MDE voce precisa do Sysmon com eventos 19, 20 e 21 habilitados. Combine com Get-WmiObject -Namespace root\subscription -Class __EventConsumer rodando semanalmente como compliance check. Tecnicas de movimentacao que terminam em persistencia WMI estao bem ilustradas em Lateral Movement em Lab: SMB, WMI e WinRM com Foco em Deteccao.

COM hijacking (T1546.015) explora a precedencia de HKCU sobre HKLM em CLSIDs. O atacante registra um InProcServer32 em HKCU apontando para uma DLL controlada, e qualquer processo que carregue aquele CLSID em sessao de usuario executa o codigo. Para cacar, foque em escritas inesperadas em HKCU\Software\Classes\CLSID\*\InProcServer32 onde o valor padrao nao termina em DLL assinada pela Microsoft. AppInit_DLLs (T1546.010) e Image File Execution Options (T1546.012) entram na mesma categoria de abuso de registry-based execution flow e merecem queries dedicadas. Quem quer entender por que evasao moderna ainda passa por aqui deve ler Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao.

Startup folder, Logon Scripts (T1037), BITS Jobs (T1197) e Print Processors (T1547.012) fecham a lista pratica. BITS merece atencao especial porque sobrevive a logoff e pode baixar payloads usando processo confiavel: bitsadmin /list /allusers /verbose como check semanal ja pega 95% dos casos. Print Processors voltaram ao mapa depois do PrintNightmare e o monitoramento do registro HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments e barato. Para correlacionar isso com o ciclo ofensivo completo, Adversary Emulation com Caldera e MITRE ATT&CK em Lab Corporativo e Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue mostram como transformar essas deteccoes em exercicios continuos com o red team.

O takeaway pratico: empilhe as dez queries acima em uma watchlist unica no Sentinel, configure baseline de 14 dias por host antes de alertar e revise os hits em janela semanal de threat hunting. Persistencia nao e detectada com uma regra brilhante, e detectada com disciplina de revisao. Comece amanha rodando as duas primeiras queries (Run keys e schtasks) no seu ambiente de producao em modo somente-leitura, conte quantos hits voce tem, e voce vai descobrir que ja existe persistencia legitima que ninguem documentou. Esse e o ponto de partida real do programa.