TH.8 - Técnica de Stack Counting

Controle TH.8 do grupo HNT (Threat Hunting) da seção "15 - Framework CTH - Controles".
Deriva do Capítulo 12 do PDF de referência, seção 12.3. Formaliza a técnica de stack counting, que
conta ocorrências por pilha de atributos e concentra a investigação nos eventos raros, sobretudo
onde as baselines do INS.5 mostram comportamento estatisticamente previsível.

1. Contexto e Posicionamento no Framework CTH

O stack counting explora uma propriedade estatística dos ambientes corporativos: a maioria dos eventos segue distribuições previsíveis, com poucos valores dominando e uma longa cauda de valores raros. Poucos processos respondem por quase toda a execução, poucos destinos recebem quase todo o tráfego, e as mesmas tarefas agendadas aparecem em todas as máquinas da imagem padrão. Nesse cenário, eventos estatisticamente raros são candidatos naturais a investigação, porque representam desvios do padrão que podem indicar atividade adversária.

No Framework CTH, o TH.8 é uma técnica de execução que materializa o princípio do outlier: contar ocorrências de valores em campos de eventos, ordenar por frequência e examinar sistematicamente as caudas da distribuição. O TH.8.2 orienta começar por campos como image_loaded, process_name, dest_ip e dns_query, sinalizando valores com contagens muito baixas; o TH.8.3 acrescenta limiares estatísticos por desvio padrão ou percentis, com atenção aos extremos abaixo do percentil 5 e acima do percentil 95.

A técnica se apoia diretamente nas baselines do INS.5, que definem o que é normal em cada população de ativos, e complementa o TH.7 e o TH.9 no conjunto de agregação do grupo HNT. Enquanto o grouping pergunta "onde mais esse artefato apareceu", o stack counting pergunta "o que aparece pouco demais ou demais para ser normal", e os dois métodos frequentemente se alternam dentro do mesmo hunt.

2. Definição e Origem Prática da Técnica

Stack counting é a contagem de ocorrências por pilha de atributos, seguida do exame dos valores raros no topo e na base da distribuição ordenada. A pilha é o par campo e valor agregado, como "todos os processos executados nas estações, contados por nome e caminho do executável". O produto da técnica é uma tabela ordenada por frequência, em que os valores mais raros sobem para o topo da análise, independentemente de parecerem suspeitos à primeira vista.

A técnica tem origem na prática da comunidade de threat hunting, consolidada por caçadores que operavam ambientes corporativos de dezenas de milhares de endpoints no meio da década de 2010. A percepção de base é modesta e poderosa: adversários precisam executar algo, e o que executam não está na cauda dominante da distribuição, porque software legítimo de massa domina essa cauda. Publicações comunitárias sobre caça a partir de pilhas de processos, drivers e tarefas agendadas transformaram o método em prática padrão de mercado, sem exigir ferramentas especiais além de agregações que qualquer SIEM oferece.

O método aplica a regra de Pareto em versão defensiva, como registra o próprio TH.8: focar nos valores cuja frequência difere significativamente do esperado. A raridade não é veredito, é prioridade. Um processo raro pode ser software de nicho instalado por um desenvolvedor; a função do stack counting é garantir que nada raro passe sem uma decisão documentada de benignidade ou malícia.

3. Pilhas Úteis na Prática

A escolha da pilha deriva da hipótese do TH.6 e da população a analisar. A mesma pilha de processos que funciona em estações padronizadas vira ruído em servidores de aplicação, e por isso a segmentação da população é parte da definição da pilha, e não um ajuste posterior. O TH.8.1 exige ao menos uma pilha relevante por hipótese, com análise sistemática dos outliers, tanto os muito raros quanto os muito frequentes.

4. Passos Práticos de Aplicação

• Escolher a pilha e a população: definir o campo ou a combinação de campos a contar e delimitar o escopo, por tipo de ativo, unidade organizacional ou janela de tempo. A delimitação é o que garante comparabilidade entre os valores contados.
• Contar e ordenar: executar a agregação por frequência e ordenar do mais raro ao mais comum. O objetivo é um quadro compacto, com contagem total, número de hosts e de usuários por valor.
• Investigar as caudas raras: para cada valor raro, abrir a trajetória completa, com hosts, usuários, primeira e última ocorrência e processo associado. Valores que aparecem uma única vez em uma única máquina merecem prioridade máxima.
• Validar benignidade ou malícia: confrontar cada valor raro com o catálogo de software, as datas de rollout, as assinaturas digitais e, quando necessário, com o time de TI. A validação gera uma decisão documentada, e não uma impressão.
• Documentar e converter: registrar o resultado do hunt, alimentar as whitelists com data de revisão, converter padrões maliciosos confirmados em detecções pelo DET.x e IOC para o TH.10.

A cadência recomendada é periódica e recorrente: pilhas de processos e tarefas agendadas aceitam execução mensal sem fadiga, enquanto pilhas de DNS e de comandos PowerShell rendem mais em janelas curtas e dirigidas por hipótese. O TH.8.4 formaliza a leitura temporal da pilha, comparando a distribuição de períodos consecutivos, e é essa leitura que revela propagação de malware em curso, visível como um valor raro cuja contagem cresce semana a semana.

5. Exemplo Completo: Processos Raros em Estações

Cenário derivado do TH.6: a hipótese é que um implant de persistência executa binário dropado em caminho de usuário nas estações. A pilha escolhida é a de processos executados em estações padronizadas, contados por nome e caminho, com janela de 30 dias e corte de raridade em cinco ocorrências.

// Pilha de processos raros em estações de trabalho, janela de 30 dias
DeviceProcessEvents
| where Timestamp > ago(30d)
| where DeviceName startswith "wks-"
| summarize Ocorrencias = count(),
            Hosts = dcount(DeviceName),
            Usuarios = dcount(InitiatingProcessAccountName)
    by FileName, FolderPath
| where Ocorrencias <= 5
| order by Ocorrencias asc

Em SPL, a mesma pilha é escrita com agregação de termos sobre o evento de criação de processo do Sysmon, mantendo o escopo nas estações pelo padrão de nome do host.

index=endpoint sourcetype=sysmon EventCode=1 host=wks-*
| stats count as ocorrencias dc(host) as hosts dc(user) as usuarios
        by process_name, process_path
| where ocorrencias <= 5
| sort + ocorrencias

A leitura segue a disciplina da técnica: o topo da tabela traz os valores mais raros, e cada um recebe uma decisão. Um binário de cliente VPN legado instalado uma vez é benigno documentado; um executável sem assinatura em %APPDATA% presente em três estações com o mesmo processo pai é suspeito e recebe pivoting pelo TH.7, com agregação por hash e por processo pai. O valor da técnica está na garantia de cobertura: nada raro fica sem decisão, mesmo sem alerta ou inteligência prévia associada.

A segunda pilha do mesmo hunt pode cobrir a fase de rede do implant. Destinos DNS raros expõem infraestrutura recém-registrada e canais de C2 pouco usados. O corte de raridade baixo, de três consultas, privilegia domínios tocados por poucas máquinas.

// Pilha de destinos DNS raros, janela de 7 dias
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where isnotempty(RemoteUrl)
| summarize Consultas = count(), Hosts = dcount(DeviceName)
    by RemoteUrl
| where Consultas <= 3
| order by Consultas asc

6. Quando Funciona Bem e Quando Falha

O stack counting rende o máximo em ambientes padronizados, com imagens corporativas, catálogo de software controlado e rollout disciplinado. Nessas condições, a cauda dominante é de fato dominante, e qualquer valor raro salta aos olhos. A técnica é especialmente forte em pilhas de processos, tarefas agendadas, serviços e drivers, porque esses artefatos refletem diretamente a imagem base e raramente mudam sem gestão de mudança.

A técnica falha quando a população é heterogênea. Servidores são atípicos por natureza, cada um com seu conjunto próprio de serviços, e neles o conceito de "raro" perde sentido comparativo. Estações de desenvolvedores, filiais com ferramentas locais e ambientes pós-fusão sem padronização produzem caudas raras tão longas que a investigação de todas é inviável. A mitigação é segmentar: pilhas por tipo de ativo, por unidade organizacional ou por aplicação, cada uma com sua referência de normalidade, em vez de uma pilha global que mistura populações incomparáveis.

Há ainda a limitação conceitual de que raridade é frágil diante de adversário preparado. Ferramentas de Living off the Land executam a partir de binários legítimos já presentes na cauda dominante, e um ataque bem ensaiado pode parecer comum na pilha. Por isso o stack counting nunca é o único método do hunt: ele coexiste com o TH.7, que rastreia artefatos específicos, e com o TH.9, que compara comportamento entre entidades.

7. Variações da Técnica

A pilha dupla cruza dois atributos e reduz drasticamente o ruído da cauda rara. Contar processos por nome isola milhares de valores raros; contar pela combinação de processo pai e processo filho isola relações raras, que são muito mais informativas, pois um binário legítimo filho de um pai incomum é o padrão clássico de execução maliciosa.

DeviceProcessEvents
| where Timestamp > ago(30d) and DeviceName startswith "wks-"
| summarize Ocorrencias = count(), Hosts = dcount(DeviceName)
    by InitiatingProcessFileName, FileName
| where Ocorrencias <= 3
| order by Ocorrencias asc

A variação temporal compara a mesma pilha entre períodos, destacando valores novos no ambiente e valores cuja frequência cresceu abruptamente, como orienta o TH.8.4. A variação estatística, do TH.8.3, troca o corte fixo por limiares de percentil ou desvio padrão, e o nível avançado do TH.8.5 automatiza o monitoramento de outliers com modelos estatísticos, como z-score, IQR e isolation forest, transformando a técnica pontual em detecção contínua.

8. Conversão de Achados em Detecção

Todo valor raro validado gera um artefato do programa. O benigno documentado entra na whitelist com data de revisão e responsável, evitando que a mesma validação se repita a cada execução da pilha. O suspeito confirmado vira regra de detecção permanente pelo DET.x, IOC pelo TH.10 e, quando há comprometimento real, abertura no IR.x.

title: Execução de binário em caminho de usuário em estação
status: experimental
logsource:
    product: windows
    service: sysmon
detection:
    selection_path:
        Image|startswith: 'C:\Users\'
    filter_conhecidos:
        Image|endswith:
            - '\chrome.exe'
            - '\Teams.exe'
    condition: selection_path and not filter_conhecidos

A regra acima generaliza o padrão confirmado sem se prender ao hash único, cobrindo variantes que o stack counting não veria na próxima janela. O loop de melhoria fecha com o MET.x medindo quantas detecções permanentes nasceram de pilhas e com o AUT.x absorvendo as pilhas recorrentes em rotinas agendadas, liberando o hunter para as caudas realmente novas.

9. Salvaguardas por Nível de Maturidade

10. Erros Comuns e Integração com Outros Controles

• Aplicar a pilha sobre população heterogênea sem segmentar, produzindo caudas raras longas demais para investigar e desestimulando a técnica.
• Tratar raridade como veredito: evento raro é prioridade de investigação, e a malícia exige validação por evidência em cada caso.
• Ignorar a cauda alta da distribuição, onde contagens anormalmente elevadas sinalizam propagação interna e picos de atividade automatizada.
• Manter whitelist sem data de revisão, que cresce indefinidamente e transforma a pilha em tabela cega de exceções antigas.
• Executar a mesma pilha única em todos os hunts, sem combinar pilhas complementares, como processos, tarefas agendadas e DNS, que revelam fases distintas do ataque.

A integração é direta com o INS.5, que fornece as baselines que dão significado estatístico à contagem, e com o TH.6, cuja hipótese define a pilha e o critério de raridade aceitável. O TH.7 recebe os valores raros suspeitos como âncoras de pivoting; o DAT.x garante a cobertura de telemetria que sustenta a contagem; o DET.x, o TH.10 e o IR.x recebem os achados convertidos; o AUT.x automatiza as pilhas recorrentes. Operado com essa disciplina, o stack counting é a técnica de melhor custo e benefício do grupo HNT para ambientes padronizados, pois exige apenas agregações básicas de SIEM e entrega cobertura ampla contra o desconhecido.