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, mapear cada uma ao seu ID do MITRE ATT&CK e entregar queries KQL que o seu Defender XDR ou Sentinel pode rodar amanha de manha, junto da contramedida que fecha cada porta.

1. Chaves de registro de execucao automatica (T1547.001)#

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. A contramedida e um baseline por usuario mais AppLocker ou WDAC bloqueando execucao a partir de paths gravaveis pelo usuario, para que nem uma chave Run escrita consiga lancar. 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.

2. Scheduled Tasks (T1053.005)#

Scheduled Tasks 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. A contramedida e alertar sobre criacao de task fora de janelas de mudanca e negar o registro de tasks a nao-admins via GPO.

3. Servicos Windows (T1543.003)#

Servicos Windows 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. A contramedida e quotar cada path de servico, restringir SeCreateServicePrivilege e forcar code-signing. Esse padrao ecoa o que cobrimos em Hunting de Living-off-the-Land Binaries no Windows com KQL sobre baseline-driven detection.

4. WMI Event Subscription (T1546.003)#

WMI Event Subscription 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; um CommandLineEventConsumer ou ActiveScriptEventConsumer num endpoint quase nunca e legitimo. Tecnicas de movimentacao que terminam em persistencia WMI estao bem ilustradas em Lateral Movement em Lab: SMB, WMI e WinRM com Foco em Deteccao.

5. COM Hijacking (T1546.015)#

COM hijacking 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. A contramedida e fazer baseline de quais CLSIDs cada host sobrescreve em HKCU legitimamente (normalmente nenhum) e alertar sobre qualquer entrada nova, ja que uma imagem corporativa limpa quase nunca povoa essa chave.

6. AppInit_DLLs e Image File Execution Options (T1546.010 / T1546.012)#

AppInit_DLLs e Image File Execution Options entram na mesma categoria de abuso de registry-based execution flow e merecem queries dedicadas. AppInit_DLLs carrega uma DLL em todo processo que linka user32.dll, e o Windows moderno o desabilita sob Secure Boot, entao sua mera ativacao e uma bandeira vermelha: alerte sobre qualquer escrita em HKLM\...\Windows\AppInit_DLLs. O abuso de IFEO seta um valor Debugger sob a chave de um executavel alvo, de modo que lancar, digamos, sethc.exe roda o binario do atacante; cace escritas nos valores Debugger e GlobalFlag e correlacione com processos filho inesperados. Quem quer entender por que evasao moderna ainda passa por aqui deve ler Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao.

7. Startup folder e Logon Scripts (T1037)#

O Startup folder e os Logon Scripts fecham o trio classico de user-land. Um atalho solto no Startup folder por usuario ou para todos roda no logon sem elevacao, e o valor de registro UserInitMprLogonScript sob HKCU\Environment executa um script em todo logon voando abaixo da maioria dos conjuntos de regras padrao. Cace eventos de criacao de arquivo nos dois paths Startup onde o processo que escreve nao e um instalador conhecido, e alerte sobre qualquer valor em UserInitMprLogonScript, que fica vazio num host limpo. A contramedida e uma ACL travada do Startup folder e auditoria via GPO dos valores de registro de logon-script.

8. BITS Jobs (T1197)#

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, e o log Microsoft-Windows-Bits-Client/Operational registra criacao de jobs e comandos de notify. A variante perigosa seta um SetNotifyCmdLine para que o proprio BITS lance o payload quando a transferencia termina, o que parece atividade de svchost para um analista desatento. A contramedida e monitorar o canal operacional do BITS por jobs com notify command line e limitar o tempo de vida dos jobs por politica para que uma transferencia travada nao fique a espreita por semanas.

9. Print Processors e outras extensoes de autostart (T1547.012)#

Print Processors voltaram ao mapa depois do PrintNightmare e o monitoramento do registro HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments e barato: uma nova DLL de print processor carregada pelo spoolsv.exe a partir de um path nao padrao e um sinal de alta confianca. A mesma familia de autostart de boot e logon (T1547) inclui manipulacao de Winlogon Shell e Userinit, LSA Security Support Providers e DLLs helper do Netsh; cada uma e um unico valor de registro que nunca deveria mudar num host gerenciado, entao uma query de compliance comparando valores atuais contra uma golden image pega todas de uma vez. A contramedida e a mesma em todo lugar: conheca o valor bom, alerte sobre o desvio.

10. Transformar deteccoes em um programa#

A decima tecnica e a que amarra as outras nove: operacionalizar a deteccao como um programa repetivel em vez de um monte de regras. 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. 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, para que cada regra seja exercitada, afinada e re-validada em cadencia em vez de apodrecer.

Priorizar as dez por prevalencia e custo#

Nem as dez tecnicas merecem o mesmo esforco no primeiro dia, e um programa que tenta ferver o oceano empaca antes de entregar qualquer coisa. Ordene-as por prevalencia contra custo de deteccao: chaves Run e scheduled tasks sao de alta prevalencia e baixo custo, entao vem primeiro; servicos Windows e BITS sao de prevalencia media e baratos de consultar, entao vem em segundo; WMI Event Subscription, COM hijacking e a familia IFEO ou AppInit sao de menor prevalencia mas de impacto bem maior quando aparecem, porque sinalizam um operador mais capaz, entao vem em terceiro mas nao se pula. Print Processors e os valores de autostart Winlogon ou Userinit sao raros mas trivialmente baratos como comparacao contra golden image, entao integre-os na mesma varredura semanal de compliance. Mapeie cada tecnica quanto a se prevencao, deteccao ou ambas sao realistas na sua frota, porque algumas, como os unquoted service paths, se corrigem melhor uma vez do que se vigiam para sempre, enquanto outras, como as subscriptions WMI, so podem ser detectadas e revisadas. Outro fator decisivo e onde a persistencia vive: a mesma tecnica num quiosque e um indicio de baixa prioridade, num controlador de dominio ou num host de assinatura de codigo e um alerta do nivel mais alto, entao pondere cada deteccao pela criticidade do ativo. Publicar essa ordem como uma matriz de uma pagina mantem o programa honesto.

FAQ#

Qual tecnica um time pequeno deve detectar primeiro? Chaves Run e scheduled tasks, nessa ordem, porque cobrem a maioria da persistencia commodity e as queries sao baratas; deixe essas duas limpas antes de tocar nas subscriptions WMI. Preciso de Sysmon se ja rodo Defender for Endpoint? Para a maioria o MDE basta, mas WMI Event Subscription (eventos 19-21) e parte da visibilidade de escritas de registro sao mais fortes com Sysmon, entao rode Sysmon nos seus hosts joia-da-coroa e de alto risco mesmo que a frota dependa so do MDE. Cobertura e um espectro, e voce gasta Sysmon onde o raio de impacto e maior.

Checklist e conclusao#

O takeaway pratico: persistencia nao e detectada com uma regra brilhante, e detectada com disciplina de revisao. Percorra a checklist para cada uma das dez: canal de telemetria coletado, query KQL escrita e versionada, baseline por host estabelecido, contramedida implantada, e a regra validada com Atomic Red Team para voce ter visto ela disparar. 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, e tudo depois disso e iteracao disciplinada.