Hunting por Persistência (Run Keys, Scheduled Tasks)

Nota 01 do Capítulo 08, "Técnicas de Hunting por TTPs", que traduz o processo de hunting
dos capítulos 06 e 07 em hipóteses e consultas concretas por tática do MITRE ATT&CK, começando
pela Persistência (TA0003). Dialoga com as notas de TTPs do capítulo 03, com as técnicas TH.6,
TH.7 e TH.8 do framework CTH e com o capítulo 18, que converte achados de caça em detecções.

1. Contexto e Posicionamento na Biblioteca

A Persistência é a tática em que o adversário busca sobreviver a reinicializações, expiração de sessões e limpezas rotineiras do ambiente, e é também uma das mais produtivas para hunting porque exige que o atacante deixe artefatos estáveis no host: chaves de registro, tarefas agendadas, serviços instalados e assinaturas de eventos WMI. Diferentemente de fases curtas, como execução e descoberta, os mecanismos de persistência costumam permanecer ativos por dias ou semanas, ampliando a janela de detecção inclusive em caças retrospectivas sobre dados antigos. Por isso, caçar persistência é uma prática de alto retorno mesmo para equipes com telemetria limitada, pois quase todo mecanismo robusto precisa se materializar em algo persistente e observável.

Esta nota organiza a caça da tática em quatro frentes: mapear as técnicas e a telemetria que cada uma produz, formular hipóteses estruturadas no padrão do TH.6, executar consultas em KQL com os identificadores de eventos corretos e reconhecer os padrões anômalos que separam benignidade de malícia. O ciclo completo, do dado bruto à conversão em detecção permanente, segue o processo dos capítulos 06 e 07, e as referências cruzadas com o framework CTH indicam em qual controle cada passo se apoia. As notas 02 a 05 do capítulo cobrem, na mesma estrutura, movimento lateral, evasão, descoberta e coleta de credenciais.

2. Técnicas de Persistência e Telemetria Associada

Cada técnica de persistência deixa um rastro de eventos previsível, e o primeiro passo do hunt é garantir que esse rastro esteja sendo coletado. A tabela a seguir consolida as técnicas mais usadas em ambiente Windows, com seus identificadores no MITRE ATT&CK, os eventos que revelam cada ação e a fonte de coleta correspondente.

A leitura da tabela orienta o inventário de telemetria do DAT.1: sem Sysmon 13 e sem auditoria de registro, as Run Keys são praticamente invisíveis; sem o log System, o evento 7045 de instalação de serviço desaparece; e sem Sysmon 19 a 21, toda a família de WMI Event Subscription fica fora do alcance do caçador. Essa dependência é a razão pela qual a nota TH.1 exige inventário explícito das fontes antes de qualquer hipótese, e por isso a validação de cobertura é parte do hunt de persistência, e não um passo opcional.

3. Hipóteses de Caça por Persistência

As hipóteses seguem o formato SE e ENTÃO consolidado no TH.6, conectando um pressuposto de comportamento adversário a um dado que deve existir na telemetria. Hipóteses bem formuladas para esta tática incluem:

• SE uma chave Run foi criada apontando para binário em caminho de usuário ou em ProgramData, ENTÃO deve existir evento Sysmon 13 ou 4657 cujo valor do dado aponte para esse caminho, com contexto do processo criador.
• SE um atacante instalou tarefa agendada com conta SYSTEM executando fora da janela de gestão de mudanças, ENTÃO devem existir eventos 4698 e 4700 cujo conteúdo XML da tarefa revele o comando executado.
• SE um implant instalou serviço com caminho binário não padrão ou sem assinatura, ENTÃO deve existir evento 7045 ou 4697 com ImagePath em local atípico e conta criadora sem histórico de criação de serviços.
• SE o adversário usou WMI Event Subscription para sobreviver a reinicializações, ENTÃO devem existir eventos Sysmon 19, 20 e 21 correlacionados na mesma linha de tempo, quase sempre criados por processos não padrão.
• SE o binário referenciado por qualquer mecanismo de persistência não está no catálogo de software, ENTÃO a pilha de hashes desse mecanismo deve exibir o hash como outlier estatístico na contagem do TH.8.

Cada hipótese deve ser registrada com escopo, janela de tempo e critério de falsa positivo antes da execução, exatamente como orienta o TH.6.1. Em persistência, o critério de benignidade costuma ser verificável em catálogo: o binário existe no inventário, possui assinatura válida e o criador tem histórico documentado. O que não se encaixa nesse roteiro sobe para investigação.

4. Consultas Práticas em KQL

4.1 Serviços instalados com caminho atípico

O evento 7045 chega pelo log System e o 4697 pelo log Security; em Sentinel, o 7045 é consultado na tabela Event com o XML de EventData parseado, enquanto o 4697 já expõe campos normalizados na tabela SecurityEvent. A consulta prioriza caminhos de escrita que serviços legítimos raramente usam.

Event
| where EventID == 7045 and Source startswith "Microsoft-Windows-"
| extend X = parse_xml(EventData).DataItem.EventData.Data
| extend ServiceName = tostring(X[0]["@text"]),
         ImagePath   = tostring(X[1]["@text"]),
         Account     = tostring(X[4]["@text"])
| where ImagePath has "\\Users\\" or ImagePath has "\\ProgramData\\"
        or ImagePath has "\\Temp\\" or ImagePath has "\\AppData\\"
| project TimeGenerated, Computer, ServiceName, ImagePath, Account

A variante sobre SecurityEvent usa os campos nativos do 4697 e cruza com o sujeito da ação, útil para responder quem criou o serviço, informação que o 7045 não traz com a mesma riqueza.

SecurityEvent
| where EventID == 4697
| where ServiceFileName has "\\Users\\" or ServiceFileName has "\\ProgramData\\"
        or ServiceFileName !contains "\\System32\\"
| project TimeGenerated, Computer, SubjectUserName, ServiceName, ServiceFileName, ServiceStartType

4.2 Tarefas agendadas criadas e atualizadas

Os índices 4 e 5 do XML do 4698 correspondem a TaskName e TaskContent no schema canônico do evento; validar a ordem contra um evento real do próprio ambiente é um passo obrigatório, porque coletores intermediários podem alterar a estrutura. A busca por interpretadores no conteúdo da tarefa captura a forma mais comum de abuso.

SecurityEvent
| where EventID in (4698, 4702)
| extend X = parse_xml(EventData).DataItem.EventData.Data
| extend TaskName    = tostring(X[4]["@text"]),
         TaskContent = tostring(X[5]["@text"]),
         Creator     = tostring(X[1]["@text"])
| where TaskContent has_any ("powershell", "cmd.exe", "wscript", "cscript",
                             "mshta", "rundll32", "regsvr32", "schtasks")
| project TimeGenerated, Computer, EventID, Creator, TaskName, TaskContent

4.3 Run Keys por Sysmon e por EDR

Na telemetria do Microsoft Defender for Endpoint, a tabela DeviceRegistryEvents elimina o risco de índices posicionais e expõe o processo criador, o que permite julgar se o pai da escrita é um instalador legítimo ou um interpretador suspeito.

DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has "\\CurrentVersion\\Run" or RegistryKey has "\\CurrentVersion\\RunOnce"
        or RegistryKey has "\\Policies\\Explorer\\Run"
| where InitiatingProcessFileName !in~ ("msiexec.exe", "sccm*.exe", "IntuneManagementExtension.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName,
          RegistryKey, RegistryValueName, RegistryValueData

Para assinaturas WMI, a consulta sobre Sysmon 19, 20 e 21 prioriza consumidores de execução de comando, que em ambiente corporativo bem administrado são raros o suficiente para que qualquer ocorrência mereça investigação, princípio do TH.8 aplicado à tática.

Event
| where Source == "Microsoft-Windows-Sysmon" and EventID in (19, 20, 21)
| extend X = tostring(parse_xml(EventData))
| where X has "__EventFilter" or X has "CommandLineEventConsumer"
        or X has "ActiveScriptEventConsumer"
| project TimeGenerated, Computer, EventID, X

5. Padrões Anômalos e Critérios de Priorização

O julgamento de uma ocorrência de persistência combina quatro sinais que raramente apontam malícia sozinhos, mas que, juntos, elevam a prioridade de investigação. O pai inesperado é o primeiro: chave Run ou tarefa criada por rundll32, wscript, powershell ou por um binário desconhecido difere do padrão de instalação corporativa, em que msiexec e clientes de gerenciamento dominam as escritas. O caminho de escrita estranho é o segundo: binários em caminhos de usuário, em ProgramData ou em nomes que imitam System32, como System32x ou System3 2 com espaço, são clássicos de masquerading e merecem comparação byte a byte com o caminho real. O hash desconhecido é o terceiro, avaliado contra o catálogo de software e contra a pilha de raridade do TH.8. O quarto sinal é temporal e de conta: criação fora da janela de gestão de mudanças, por conta sem histórico prévio dessas ações, com prioridade ainda maior quando o sujeito é uma conta de serviço.

6. Exemplo de Caça Completa

Cenário: a inteligência do capítulo 05 registra que um implant de um grupo do crime financeiro cria chave Run apontando para binário em ProgramData com nome imitando serviço de atualização. A hipótese do TH.6 é formulada, e a primeira consulta empilha os valores de Run por máquina, buscando raridade na frota em janela de 30 dias.

DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has "\\CurrentVersion\\Run"
| summarize Ocorrencias = count(), Hosts = dcount(DeviceName)
    by RegistryValueName, RegistryValueData
| where Hosts <= 2
| order by Hosts asc

A pilha retorna um valor cujo dado aponta para C:\ProgramData\WinUpd\WinUpdSvc.exe em duas estações, hash ausente do catálogo e sem assinatura. O pivoting do TH.7 pergunta onde mais o binário apareceu e quem o criou, usando o contexto do processo no mesmo evento de registro para recuperar a cadeia de execução com Sysmon 1 ou DeviceProcessEvents, o que revela um PowerShell decodificado a partir de e-mail como origem. Com o caso confirmado, a erradicação remove a chave e o binário nas duas máquinas, a inteligência enriquece o perfil do grupo e o capítulo 18 recebe a regra Sigma que generaliza o padrão de valor de Run apontando para ProgramData com executável não catalogado.

7. Erros Comuns e Pontos de Atenção

• Tratar todo 7045 como suspeito: atualizações de software e agentes corporativos criam serviços constantemente, e a priorização deve combinar caminho, assinatura, conta criadora e janela de mudança, sob pena de fadiga do caçador.
• Ignorar que o Sysmon omite campos vazios e desloca índices posicionais no XML: validar o schema com um evento real do ambiente antes de confiar nos índices 0, 4, 5 e 6 usados nas consultas.
• Cobrir apenas a chave Run e esquecer RunOnce, Policies\Explorer\Run, o hive Wow6432Node e as pastas Startup de usuário e de "Todos os Programas", vias que atacantes exploram justamente por serem menos monitoradas.
• Descartar o 4702, atualização de tarefa agendada, que é a via mais discreta de instalar persistência sobre uma tarefa legítima já existente, herdando a aparência benigna do nome dela.
• Assumir que WMI Event Subscription está coberto: sem Sysmon 19 a 21 a técnica é invisível, e a ausência de achados nessa frente não prova nada, apenas reflete o inventário do DAT.1.

8. Integração com o Restante da Biblioteca

A caça de persistência consome as baselines do INS.5, que definem quais serviços, tarefas e valores de registro são normais por população de ativos, e usa as técnicas TH.6, TH.7 e TH.8 como espinha de formulação, pivoting e contagem. Os achados benignos documentados alimentam as whitelists com data de revisão, os achados maliciosos se convertem em detecções pelo capítulo 18 e pelo controle DET.x, e o comprometimento confirmado abre a trilha do IR.x, onde a remoção do mecanismo de persistência é requisito formal de erradicação. A inteligência produzida retroalimenta o capítulo 05 com as TTPs observadas.

Uma orientação operacional fecha a nota: serviços e tarefas agendadas produzem ruído baixo e aceitam caça recorrente mensal com fadiga mínima, enquanto assinaturas WMI são tão raras em frotas corporativas que qualquer consumidor não padrão, em qualquer momento, justifica investigação imediata, dispensando até a acumulação de janela estatística. Essa assimetria de cadência, alta frequência para mecanismos comuns e disparo imediato para mecanismos raros, é o padrão de operação que as demais notas do capítulo reutilizam em outras táticas.