TH.9 - Técnica de Clustering

Controle TH.9 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.4. Formaliza a técnica de clustering, que reúne
entidades com comportamento similar para revelar o que destoa e o que anda junto, complementando as
técnicas de agregação por atributo do TH.7 e de raridade do TH.8.

1. Contexto e Posicionamento no Framework CTH

O clustering reúne entidades com comportamento similar para que o conjunto revele o que eventos isolados escondem. Um usuário que acessa três hosts pode ser inofensivo; um grupo de quarenta usuários com o mesmo padrão de alcance, horário e recursos pode ser uma operação coordenada, e o usuário que destoa do seu próprio grupo pode ser a credencial comprometida. É esse movimento duplo, achar o que anda junto e achar o que destoa, que define a técnica.

No Framework CTH, o TH.9 é a técnica de execução mais sofisticada do grupo HNT e a que mais se aproxima da análise exploratória da caça não estruturada, sem abandonar o rigor. O TH.9.1 exige ao menos um hunt por mês com clustering básico sobre combinações de campos categóricos; o TH.9.2 aproveita o machine learning não supervisionado da plataforma de SIEM sobre campos numéricos, como bytes transferidos, duração de conexão e número de pacotes; os níveis superiores formalizam pipelines próprios e validação sistemática dos grupos.

A posição da técnica no conjunto é complementar por definição. O TH.7 agrupa por atributo conhecido, o TH.8 conta o que é raro, e o TH.9 descobre agrupamentos que ninguém especificou de antemão. Em ambientes grandes, com milhares de usuários e hosts, é frequentemente o único método capaz de produzir baseline sem fixar manualmente um limiar para cada entidade.

2. Definição e Diferença para o Grouping

Clustering é o agrupamento de entidades por similaridade de comportamento, medido sobre features extraídas da telemetria, com algoritmos que descobrem a estrutura natural dos dados. As entidades podem ser usuários, hosts, contas de serviço ou até eventos; o que define o grupo não é um atributo compartilhado declarado, mas a proximidade entre os vetores de comportamento de cada entidade. O resultado é uma partição da população em grupos, dentro dos quais os membros são parecidos entre si e diferentes dos demais.

A distinção para o grouping é o ponto de partida. O grouping (TH.7) parte de um artefato conhecido, escolhido pelo hunter a partir da hipótese, e pergunta onde mais ele apareceu. O clustering parte dos próprios dados, sem âncora, e pergunta quais entidades se comportam de forma parecida. Essa diferença muda ferramenta, risco e resultado, conforme o quadro comparativo.

3. Abordagens Leves e Avançadas

A abordagem leve dispensa algoritmos e usa regras e distâncias simples sobre features contáveis. Um exemplo clássico é ranquear usuários pela proporção de logons fora do horário comercial e investigar o topo da lista, ou combinar campos categóricos, como usuário e host, e examinar combinações que aparecem só uma vez. Essa variação cumpre o espírito do TH.9.1, exige apenas agregações de SIEM e é a porta de entrada recomendada para equipes sem rotina de dados.

A abordagem avançada aplica algoritmos clássicos sobre vetores de features. O k-means particiona a população em k grupos em torno de centroides e funciona bem quando se conhece aproximadamente o número de segmentos; o DBSCAN agrupa por densidade, não exige número fixo de grupos e ainda rotula como ruído os pontos isolados, que são exatamente os candidatos a investigação; o clustering hierárquico produz dendrogramas que permitem escolher a granularidade de análise depois de ver a estrutura. Em estágios maduros, embeddings de comportamento, representações vetoriais de sequências de atividade, substituem as features manuais, mantendo o mesmo desenho de análise.

Nenhuma dessas abordagens exige matemática profunda do hunter. O que exige é disciplina de método: padronizar as features antes de medir distância, entender o efeito dos parâmetros, como eps e min_samples do DBSCAN ou o k do k-means, e tratar o rótulo do algoritmo como hipótese a validar, e não como veredito. A matemática pesada fica nas bibliotecas, como o scikit-learn, e nas funções de ML do SIEM; a responsabilidade analítica fica no desenho das features e na validação.

Um exemplo útil de abordagem leve é o ranqueamento por proporção. Dividindo os logons de cada usuário fora da janela de 7h às 19h pelo total de logons do período, obtém-se uma feature adimensional entre 0 e 1 que dispensa algoritmos: o topo da tabela ordenada por essa proporção é, na prática, um clustering de um único atributo, e já sustenta hunts produtivos. O passo seguinte é combinar duas ou três proporções desse tipo em um escore simples, o que antecipa, com agregações básicas, o ganho analítico que os algoritmos formalizam.

4. Features Úteis por Entidade

A escolha das features é o momento mais delicado da técnica, pois define o que "parecido" significa. Features boas são contáveis, comparáveis entre entidades da mesma população e conectadas ao risco, como alcance, horário e volume. Features ruins reproduzem a estrutura organizacional, como unidade ou departamento, e produzem clusters que apenas separam o RH do financeiro, sem qualquer significado de segurança. A revisão das features deve acompanhar cada hunt, com o critério de relevância registrado junto ao resultado.

Na prática, o time mantém um dicionário de features documentado, com origem da telemetria, fórmula, população aplicável e data de revisão. Esse dicionário evita que dois hunts usem definições diferentes para a mesma feature, o que tornaria os resultados incomparáveis, e acelera a montagem de novos experimentos, pois o esforço passa a ser de combinação, e não de reconstrução.

5. Fluxo Prático em Notebook

O fluxo típico usa notebook para extrair features do SIEM, padronizar, clusterizar e inspecionar os grupos pequenos e anômalos. A extração costuma ser feita com agregação SQL sobre os logs de autenticação e de rede, produzindo uma linha por entidade. O esqueleto a seguir ilustra essa etapa de features por usuário, mantendo nomes alinhados ao notebook da sequência.

-- Extração de features por usuário sobre logs de autenticação (30 dias)
SELECT
    user_principal_name,
    COUNT(DISTINCT host)                       AS hosts_acessados,
    AVG(CASE WHEN HOUR(event_time) NOT BETWEEN 7 AND 19
             THEN 1.0 ELSE 0.0 END)            AS logons_fora_hora,
    COUNT(DISTINCT CASE WHEN recurso IN ('\\fin\\contabilidade', '\\rh\\pessoal')
                        THEN recurso END)      AS recursos_sensiveis,
    COUNT(DISTINCT tipo_origem)                AS origens_distintas
FROM auth_events
WHERE event_time > CURRENT_DATE - INTERVAL 30 DAY
GROUP BY user_principal_name

Com as features em mãos, o notebook padroniza e clusteriza. O exemplo usa DBSCAN sobre usuários, mantendo o desenho didático e o pipeline substituível por qualquer fonte de features.

import pandas as pd
from sklearn.preprocessing import StandardScaler
from sklearn.cluster import DBSCAN

# 1. Extração de features por usuário a partir do SIEM (janela de 30 dias)
usuarios = pd.DataFrame({
    "hosts_acessados": hosts_acessados,        # contagem de hosts distintos
    "logons_fora_hora": logons_fora_hora,      # proporção de logons fora do expediente
    "recursos_sensiveis": recursos_sensiveis,  # acessos a compartilhamentos críticos
    "origens_distintas": origens_distintas,    # VPN, rede interna e nuvem
})

# 2. Padronização das features e clusterização por densidade
X = StandardScaler().fit_transform(usuarios)
modelo = DBSCAN(eps=1.5, min_samples=5)
usuarios["cluster"] = modelo.fit_predict(X)

# 3. Inspeção dos clusters pequenos e dos pontos de ruído (rótulo -1)
tamanhos = usuarios.groupby("cluster").size().sort_values()
pequenos = tamanhos.head(10).index.tolist()
candidatos = usuarios[usuarios["cluster"].isin(pequenos + [-1])]

A leitura do resultado segue uma ordem fixa: primeiro os pontos de ruído do DBSCAN, rotulados como -1, que são entidades sem vizinhança suficiente e candidatos máximos; depois os clusters pequenos, que podem ser tanto grupos de risco quanto grupos de papéis raros, como administradores; por último, um cluster dominante amostrado, que serve de controle do que o desenho considera normal. Cada candidato recebe investigação individual, com pivoting pelo TH.7 quando emerge um artefato compartilhado.

A iteração é parte do fluxo, e não falha do método. Se o resultado produz um cluster gigante e muitos pontos de ruído, o eps está apertado ou as features mal dimensionadas; se tudo cai no mesmo cluster, as features não discriminam comportamento. Duas ou três iterações com ajuste de parâmetros e de features são o custo normal de uma análise bem feita, e cada iteração é registrada com seus parâmetros.

6. Validação Humana e Falsos Agrupamentos

A validação humana é obrigatória e formalizada pelo TH.9.4: investigar manualmente uma amostra representativa de cada cluster e classificar o grupo como benigno, suspeito ou malicioso. A amostra deve incluir membros típicos e membros extremos do cluster, e a classificação alimenta a calibração do modelo, ajustando features, escala e parâmetros. Um cluster sem amostragem validada é um agrupamento matemático, não um achado de hunting.

A dimensão da amostra deve ser proporcional ao grupo, com mínimo operacional de alguns membros nos clusters pequenos e algo em torno de 5% a 10% nos clusters grandes, sempre incluindo os extremos. A documentação da amostra, com os membros escolhidos e a evidência examinada, é o que permite auditar a decisão meses depois. Clusters revisados em hunts anteriores podem reusar a classificação, desde que as features e a janela de dados não tenham mudado de forma relevante.

Os falsos agrupamentos têm causas conhecidas e evitáveis. Features sem padronização deixam a variável de maior escala dominar a distância e criam grupos artificiais; features de identidade organizacional reproduzem departamentos em vez de risco; dados de entrada incompletos fazem uma entidade parecer rara por falta de telemetria, e não por comportamento; parâmetros convenientes demais colapsam a população em um único grupo. O antídoto é o mesmo em todos os casos: revisar o desenho antes de confiar no resultado e exigir evidência individual para cada entidade escalada.

É legítimo e desejável que a maioria dos clusters termine benigna. O valor acumulado está nas exceções documentadas, nas whitelists com data de revisão e nas features que provaram discriminar risco, e que passam a compor o pipeline recorrente do time. O clustering maduro é, nesse sentido, um acervo de experimentos registrados, e não uma caixa preta executada às cegas.

7. Quando Usar Clustering

O clustering é o método indicado em ambientes grandes, onde a contagem manual de exceções não escala, e onde as baselines do INS.5 são difíceis de fixar por entidade. Ele também é a escolha natural quando a pergunta do hunt não tem artefato âncora, como avaliar se há contas de usuário se comportando de forma diferente da função que exercem, ou se há hosts conversando com a internet fora do padrão da sua frota.

Ele não substitui as técnicas mais simples quando a pergunta já é específica. Alcance de artefato é trabalho do TH.7, raridade é trabalho do TH.8, e hipótese fechada do TH.6 quase sempre resolve com agregação direta. O rendimento do clustering aparece na descoberta, quando ninguém sabe o que procurar, e na cobertura contínua, quando o pipeline recorrente passa a monitorar a população inteira e sinaliza novos grupos assim que se formam, como descreve o TH.9.5.

Vale ainda distinguir o clustering artesanal de hunts do UEBA da plataforma. O UEBA entrega escores e perfis prontos por entidade, e é essencial na operação contínua; o clustering de hunt devolve controle do desenho ao analista, permitindo testar features novas, populações específicas e perguntas que o produto não contempla. Os dois coexistem, e os achados do produto costumam servir de validação cruzada para os experimentos do time.

8. Registro e Conversão em Detecção ou Nova Hipótese

O registro do hunt de clustering documenta features, fonte de dados, janela, parâmetros, versão das features, amostragem validada e veredito por cluster. Sem esse registro, o resultado é irreprodutível e o aprendizado se perde. O registro alimenta três saídas: ajuste do pipeline, para a próxima execução; conversão em detecção, quando um padrão de grupo é estável e vale regra permanente pelo DET.x ou por analytics de UEBA; e geração de novas hipóteses pelo TH.6, quando um cluster suspeito abre perguntas específicas de comportamento.

A conversão em nova hipótese é a mais valiosa na prática. Um cluster de usuários com logons fora de hora e alcance anômalo vira, por exemplo, a hipótese estruturada de que o adversário está usando credenciais de turno noturno, com cláusula SE-ENTÃO, técnica ATT&CK, fonte e critério de validação. Assim, a técnica de descoberta devolve o achado ao processo formal do programa, e o ciclo de caça continua com rigor, em vez de terminar em uma observação solta.

9. Salvaguardas por Nível de Maturidade

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

• Clusterizar sem padronizar as features, permitindo que a variável de maior escala domine a distância e defina sozinha os grupos.
• Escolher parâmetros por conveniência, produzindo um cluster gigante que não discrimina nada ou um ruído gigantesco que inviabiliza a análise.
• Tratar o rótulo do algoritmo como veredito, sem amostragem validada por cluster, em violação ao TH.9.4.
• Incluir features que apenas reproduzem a estrutura organizacional, achando "anomalias" que são diferenças de função de trabalho.
• Não registrar parâmetros, features e janela de dados, tornando o experimento irreprodutível e o aprendizado não auditável.

A integração com o Framework CTH segue o desenho das demais técnicas do grupo. O TH.6 recebe as novas hipóteses geradas pelos clusters suspeitos; o TH.7 e o TH.8 recebem os pivôs emergentes dos grupos; o INS.5 ganha baselines comportamentais derivadas dos clusters benignos validados; o DAT.x fornece as features e recebe pedidos de nova telemetria; o DET.x e o AUT.x recebem as detecções e os pipelines recorrentes; o MET.x mede conversão de clusters em achados e detecções. Operado com validação disciplinada, o clustering estende a caça ao território onde não existe artefato, assinatura ou hipótese pronta.