Detectar persistencia: um guia de caca para blue team

Uma intrusao raramente e um unico momento. Depois que um adversario ganha um ponto de apoio, sua primeira prioridade e garantir que possa voltar mesmo se a maquina reiniciar, a senha mudar ou o ponto de entrada original for fechado. Essa capacidade se chama persistencia, e caca-la e uma das atividades de maior valor que um blue team realiza. Este guia adota uma postura defensiva: descrevemos as categorias de persistencia para que voce reconheca seus rastros, focamos na telemetria, nos Event IDs e nos fluxos de caca que os revelam, e encerramos com endurecimento. O objetivo e ensinar deteccao e erradicacao, nao dar a ninguem uma receita para permanecer oculto. Se voce consegue encontrar persistencia de forma confiavel, transforma um comprometimento persistente em um incidente contido.

O que e persistencia e por que importa#

Persistencia e qualquer mecanismo que permite a um adversario manter o acesso a um sistema atraves de interrupcoes como reinicializacoes, logoffs ou redefinicoes de credenciais. No framework MITRE ATT&CK e a tatica TA0003, e esta no coracao do porque as intrusoes se tornam longevas. A verdade incomoda para os defensores e que a erradicacao falha sempre que a persistencia e ignorada: voce pode remover o malware, rotacionar uma senha e reconstruir um servico, mas se o atacante deixou uma tarefa agendada, uma conta ilicita ou uma entrada de inicializacao modificada, ele simplesmente volta a entrar. Por isso a resposta a incidentes sempre inclui uma caca deliberada de persistencia antes de declarar um sistema limpo. Encontrar a carga inicial nao e a linha de chegada; encontrar cada ponto de apoio e.

A mentalidade de persistencia para defensores#

A caca eficaz parte de uma premissa simples: um atacante que quer sobreviver a uma reinicializacao precisa deixar algo que o sistema operacional execute automaticamente. Essa restricao e sua vantagem, porque o conjunto de lugares onde o SO procura coisas para executar e finito e bem documentado. Em vez de perseguir possibilidades infinitas, voce enumera os locais de autoinicializacao conhecidos e pergunta, para cada um, se o que vive ali e o esperado. A disciplina e o baselining: saber como o normal se parece para que as anomalias se destaquem. Uma tarefa agendada criada as tres da manha por um usuario que nunca faz scripts, um servico apontando para um binario em uma pasta temporaria, ou uma nova conta de administrador local nao sao sutis assim que voce tem uma linha de base para comparar.

Onde a persistencia se esconde no Windows#

No Windows, os defensores devem revisar rotineiramente um conjunto conhecido de pontos de extensibilidade de autoinicializacao. Estes incluem as chaves de registro Run e RunOnce, tarefas agendadas, servicos do Windows, pastas de inicializacao, assinaturas de eventos WMI e o abuso de mecanismos legitimos como a ordem de busca de DLL ou recursos de acessibilidade. A persistencia baseada em conta importa igualmente: contas locais ou de dominio recem-criadas, usuarios adicionados a grupos privilegiados e scripts de logon modificados. Ferramentas como o Sysinternals Autoruns sao construidas exatamente para enumerar esses locais, e combinar isso com a telemetria do Sysmon lhe da visibilidade de criacao de processos, modificacao de registro e carregamento de imagens. O objetivo ao revisar cada local nao e memorizar cada tecnica, mas detectar a entrada que nao pertence e depois pivotar para quem a criou e quando.

Onde a persistencia se esconde no Linux#

Em sistemas Linux e Unix a superficie de autoinicializacao e diferente mas igualmente enumeravel. Trabalhos cron e timers e units do systemd sao pontos de apoio comuns, assim como arquivos de inicializacao de shell modificados como os scripts profile e rc, chaves SSH autorizadas adicionadas e definicoes de servico novas ou alteradas. Atacantes tambem abusam de tarefas agendadas que rodam como root e de arquivos de configuracao carregados no boot. Defensivamente voce revisa esses locais contra uma linha de base conhecida, observa arquivos com tempos de modificacao recentes que nenhum ticket de mudanca explica e monitora a adicao de chaves SSH a contas. Auditd e a telemetria de endpoint ajudam ao registrar a execucao de processos e as mudancas de arquivos, de modo que uma entrada cron que aparece fora do seu pipeline de implantacao se torna um sinal em vez de uma surpresa que voce acha semanas depois.

Persistencia em nuvem e de identidade#

A persistencia moderna e cada vez mais baseada em identidade e vive acima de qualquer host individual. Em ambientes de nuvem e SaaS, os atacantes buscam acesso duradouro por meio de novas credenciais em vez de arquivos: uma access key fresca em um principal de servico, uma relacao de federacao ou confianca adicionada, um aplicativo OAuth com amplas permissoes delegadas, ou uma regra oculta de encaminhamento de e-mail. Como esses mecanismos sao recursos administrativos legitimos, eles se misturam a menos que voce esteja observando o log de auditoria. Cace chaves e registros de aplicativos recem-criados, mudancas na confianca de papeis e na federacao, e concessoes de consentimento a aplicativos desconhecidos. O principio defensivo espelha o mundo do host: enumere o pequeno conjunto de lugares onde acesso duradouro pode ser plantado, estabeleca uma linha de base do esperado e trate qualquer adicao inexplicada a identidade como um possivel ponto de apoio.

Sinais de deteccao e telemetria#

A caca de persistencia e tao boa quanto a telemetria por baixo dela. No Windows, os Event IDs relevantes para seguranca sao inestimaveis: 4698 registra a criacao de tarefas agendadas, 7045 marca a instalacao de um novo servico, 4720 mostra a criacao de conta e 4732 registra um membro adicionado a um grupo com seguranca habilitada. O Sysmon adiciona eventos granulares de criacao de processos, registro e carregamento de imagens que capturam tecnicas que a politica de auditoria padrao deixa passar. No Linux, auditd e o historico de shell dao visibilidade equivalente, e as plataformas EDR unem os dois mundos com deteccao comportamental. O sinal mais poderoso, porem, e a comparacao contra uma linha de base: alerte sobre o aparecimento visto pela primeira vez de uma entrada de autoinicializacao, um servico apontando para um caminho incomum ou uma criacao de conta fora do seu processo de provisionamento. A anomalia vence a assinatura quando os adversarios vivem da terra.

Um fluxo de caca pratico#

Transforme os conceitos em uma rotina repetivel. Comece enumerando os locais de autoinicializacao pela sua frota com ferramentas que reportem chaves run do registro, tarefas agendadas, servicos e itens de inicializacao, ou seus equivalentes em Linux e nuvem. Em seguida, estabeleca a linha de base: compare o estado atual com um snapshot conhecido como bom ou com a maioria de hosts semelhantes, porque os valores atipicos sao onde voce olha primeiro. Depois enriqueca cada candidato perguntando quem o criou, quando, de qual conta e se existe um registro de mudanca correspondente. Correlacione com logs de processos e de autenticacao para construir uma linha do tempo e, por fim, valide se a entrada e benigna ou maliciosa antes de agir. Documente o que encontrar para que a proxima caca parta de uma linha de base melhor, e realimente os padroes confirmados em deteccoes automatizadas.

Mitigacao e endurecimento#

Deteccao e prevencao reforcam uma a outra. Reduza a superficie de persistencia impondo minimo privilegio para que poucas contas possam criar servicos, tarefas agendadas ou novos usuarios em primeiro lugar. Exija autenticacao multifator e monitore a participacao em grupos privilegiados para que pontos de apoio baseados em conta sejam dificeis de plantar e rapidos de notar. Centralize e proteja os logs em um local que o atacante nao possa editar, e habilite as politicas de auditoria e a configuracao de Sysmon ou auditd que tornam a persistencia visivel. O allowlisting de aplicativos limita o que pode ser executado a partir da autoinicializacao de todo. Na nuvem, restrinja quem pode cunhar credenciais e conceder consentimento, e alerte sobre mudancas de confianca e federacao. Cada controle que estreita onde acesso duradouro pode ser plantado tambem encolhe o espaco que voce precisa cacar.

Armadilhas comuns#

Varios erros deixam a persistencia sobreviver. Respondedores erradicam a carga obvia e cantam vitoria sem enumerar os locais de autoinicializacao, entao uma tarefa agendada restabelece a intrusao em silencio. As equipes cacam no host mas esquecem a persistencia de identidade na nuvem, deixando uma access key que sobrevive a reconstrucao. Faltam linhas de base, entao um servico malicioso e indistinguivel de um legitimo a primeira vista. A telemetria nao esta configurada, entao os proprios Event IDs que revelariam uma nova tarefa ou conta nunca foram registrados. E os investigadores encontram um ponto de apoio e param, sem perceber que os atacantes costumam plantar varios por redundancia. A cura e uma caca sistematica que cubra hosts e identidades, apoiada por linhas de base e telemetria completa, e uma regra de nunca declarar limpo apos encontrar apenas um.

Checklist de persistencia do blue team#

Use isto como sequencia de caca. 1. Confirme que a politica de auditoria, Sysmon ou auditd e a centralizacao de logs estejam no lugar antes de precisar delas. 2. Enumere os pontos de autoinicializacao do Windows: chaves run, tarefas agendadas, servicos, pastas de inicializacao, assinaturas WMI. 3. Enumere os equivalentes do Linux: cron, systemd, arquivos rc de shell, chaves SSH. 4. Enumere a persistencia de identidade: novas chaves, registros de aplicativos, mudancas de confianca e consentimento. 5. Estabeleca a linha de base de cada um contra hosts conhecidos como bons ou pares e sinalize os atipicos. 6. Enriqueca com correlacao de criador, carimbo de tempo e registro de mudanca. 7. Construa uma linha do tempo a partir dos Event IDs 4698, 7045, 4720, 4732 e dos logs de processos. 8. Assuma redundancia: continue cacando apos o primeiro achado. 9. Remedie, depois reverifique. 10. Realimente os padroes confirmados em deteccoes automatizadas.

FAQ: encontrar um mecanismo de persistencia basta para declarar um host limpo?#

Nao, e supor isso e um dos erros mais caros na resposta a incidentes. Os adversarios rotineiramente plantam multiplos mecanismos de persistencia justamente para que remover um nao os deixe de fora. Se voce encontra uma tarefa agendada maliciosa, trate-a como um sinal para cacar mais forte, nao como o fim da investigacao, e enumere cada outro local de autoinicializacao no host, bem como a persistencia baseada em identidade em qualquer nuvem conectada. Construa uma linha do tempo completa do que o atacante fez e quando, porque a persistencia que voce encontra muitas vezes aponta para a conta e a janela de tempo em que outros pontos de apoio foram criados. Declare um sistema limpo apenas apos uma enumeracao completa, nao apos o primeiro acerto.

FAQ: qual telemetria devo priorizar se tenho recursos limitados?#

Se voce precisa comecar pequeno, priorize os sinais que revelam os pontos de apoio mais comuns. No Windows, habilite a auditoria para criacao de tarefas agendadas, instalacao de servicos e mudancas de contas e grupos, que correspondem aos Event IDs 4698, 7045, 4720 e 4732, e implante o Sysmon para visibilidade de processos e registro. No Linux, habilite auditd para execucao de processos e monitore cron, systemd e as chaves SSH autorizadas. Na nuvem, capture o log de auditoria de identidade e alerte sobre novas credenciais e mudancas de confianca. Centralize tudo isso em algum lugar que o atacante nao possa alterar. Com isso no lugar voce cobre uma grande fracao da persistencia do mundo real e pode expandir a cobertura conforme os recursos permitirem.

Conclusao#

A persistencia e o que transforma uma intrusao breve em uma longa, e caca-la e o que transforma uma longa de volta em um incidente contido. A vantagem do defensor e estrutural: o sistema operacional e as plataformas de nuvem procuram itens de autoinicializacao e credenciais duradouras em um conjunto finito e documentado de lugares, entao uma caca disciplinada pode cobri-los todos. Habilite primeiro a telemetria, estabeleca a linha de base do que e normal, enumere os pontos de apoio de host e identidade, correlacione os eventos de criacao em uma linha do tempo e nunca declare limpo apos um unico achado. Combine a deteccao com minimo privilegio e allowlisting para que haja menos lugares onde plantar um ponto de apoio desde o inicio. Feita de forma consistente, a caca de persistencia e o passo que torna a erradicacao real.