Threat hunting para PMEs portuguesas — o que é e quando precisa
A maioria das PMEs tem antivírus; quase nenhuma faz threat hunting. O que é, quando uma PME passa de "antivírus chega" para "preciso de mais", e como obter a capacidade sem montar um SOC interno.
Resposta rápida: Threat hunting é a procura ativa de atacantes já presentes na rede que as ferramentas reativas (antivírus, EDR) não detetaram. Uma PME precisa dele quando opera em sector regulado (NIS2 EE/EI), detém ativos de alto valor, ou já sofreu um incidente. Reduz o dwell time mediano de mais de 80 dias para menos de 10.
A maioria das PMEs portuguesas tem antivírus. Algumas têm EDR. Quase nenhuma faz threat hunting. E não é por falta de necessidade — o relatório do CNCS Riscos & Conflitos 2025 documenta um aumento claro em ataques sofisticados que evitam deliberadamente as ferramentas reactivas. Threat hunting é a resposta a este tipo de ameaça: procurar activamente o que ainda ninguém detectou.
Este guia explica o que é threat hunting na prática, quando uma PME passa do nível "antivírus chega" para "preciso de mais", e como obter a capacidade sem montar um SOC interno.
Antivírus reage. Threat hunting procura.
A diferença mental entre ferramentas reactivas e proactivas é simples mas frequentemente mal compreendida.
Antivírus / EDR tradicional reage. Compara ficheiros e comportamentos contra uma base de dados de ameaças conhecidas (assinaturas, hashes, padrões de comportamento). Quando há match, alerta ou bloqueia. É excelente para o que conhece. É cego para o que não conhece.
Threat hunting procura. Parte do princípio oposto: assume que já há atacantes na rede que ainda não foram detectados. Em vez de esperar pelo alerta, investiga sinais fracos — uma conexão fora-do-normal a um IP estrangeiro, uma conta de serviço a fazer login fora-de-horas, um processo legítimo (PowerShell, certutil) a comportar-se de forma atípica. Os hunters geram hipóteses ("um atacante que persistiu via scheduled task estaria a comunicar como esta?"), procuram evidência, e investigam.
Esta diferença importa porque os atacantes mais perigosos sabem como evitar ferramentas reactivas. Em incidentes reais investigados em Portugal em 2024-2025, o tempo médio entre comprometimento inicial e detecção (dwell time) foi de mais de 80 dias quando a única defesa era reactiva. Em organizações com threat hunting activo, este número cai para menos de 10 dias.
Em 80 dias, um atacante move-se lateralmente, cataloga dados, escala privilégios, instala persistência redundante, e prepara exfiltração ou ransomware. Em 10 dias, raramente sai do ponto inicial.
Os 3 modos de threat hunting
Não é uma actividade única — há três modos distintos, cada um com casos de uso diferentes.
1. Estruturado (hipótese-driven). O hunter parte de uma hipótese específica baseada em táticas conhecidas (MITRE ATT&CK). Exemplo: "Se um atacante usar Mimikatz para extrair credenciais, deve haver acesso anómalo ao processo lsass.exe nas últimas 30 dias." Investiga logs, encontra ou não encontra evidência, documenta. É o modo mais sistemático e o que melhor escala.
2. Situacional (intelligence-driven). O hunter recebe um indicador de threat intelligence (IoC) — um IP, hash, domínio — associado a um ator conhecido a operar no seu sector. Investiga se há evidência desse indicador na rede. Exemplo: "O CNCS publicou IoCs de uma campanha contra retalho português; vamos verificar tudo o que falou com aqueles domínios nos últimos 60 dias."
3. Anomaly-driven. O hunter investiga sinais que se desviam da baseline normal — sem hipótese pré-formada, mas com instinto. Exemplo: "Esta conta de serviço normalmente faz 200 requests/dia; ontem fez 12.000. Porquê?" É o modo mais difícil de automatizar e o que mais depende de experiência.
Em prática, programas maduros combinam os três. PMEs a começar tendem a focar-se no modo 2 (mais barato, melhor relação esforço/valor) e expandir para 1 e 3 ao amadurecer.
Quando uma PME precisa de threat hunting
Há red flags que indicam que antivírus + EDR já não chegam:
- Sector regulado (NIS2 EE/EI, banca, saúde, infraestrutura crítica). O DL 125/2025 não usa o termo "threat hunting", mas o nível "Substancial" do framework do CNCS exige monitorização contínua e detecção de comportamento anómalo — que na prática significa hunting.
- Activos de alto valor. Propriedade intelectual, dados de cartão de crédito (PCI-DSS), dados clínicos (RGPD), dados financeiros (DORA). O custo de uma exfiltração silenciosa supera por muito o custo do hunting.
- Cadeia de fornecimento crítica. Se servir clientes em sectores regulados, eles vão exigir-lhe demonstração de capacidade de detecção avançada. Hunting é a resposta defensável.
- Já houve um incidente. Após o primeiro incidente sério, hunting deixa de ser opcional. A administração quer saber se há outros atacantes na rede que ainda não foram detectados — e essa pergunta só se responde com hunting.
- Dimensão > 100 trabalhadores ou >€20M turnover. A partir desta dimensão, a superfície de ataque torna-se demasiado grande para depender exclusivamente de detecção reactiva.
Se nada disto se aplica, threat hunting pode ser overkill. Antivírus + EDR + backups testados + MFA cobrem a maior parte do risco para uma PME pequena, não-regulada, sem activos especialmente atractivos.
As métricas que importam
As três métricas centrais para avaliar um programa de threat hunting:
- MTTD (Mean Time to Detect). Tempo médio entre o comprometimento inicial e a detecção. Em organizações sem hunting, mediana de 80+ dias. Com hunting maduro, abaixo de 10 dias.
- MTTR (Mean Time to Respond). Tempo médio entre detecção e contenção. Hunting bem feito identifica não só o ponto de entrada mas todo o blast radius — o que acelera a resposta.
- Dwell time. Tempo total que um atacante passa na rede antes de ser expulso. Combina MTTD + tempo de erradicação. Esta é a métrica que melhor reflecte o risco real.
Cuidado com vanity metrics. "Número de alertas investigados" diz pouco — pode significar que há muitos falsos positivos. "Número de hunting queries criadas" diz menos ainda. Foque-se em MTTD e dwell time.
In-house vs gerido: o que muda na prática
Montar capacidade de hunting interna é caro e demorado. Para fazer 24/7 (que é o que a NIS2 efectivamente exige para EE), precisa de pelo menos:
- 6 analistas em rotação. 3 turnos × 2 analistas, com cobertura para férias, formação, doença.
- Tooling. SIEM (€30k–€100k/ano), EDR de classe enterprise (€20k–€80k/ano), threat intel feeds (€10k–€30k/ano), plataforma SOAR opcional.
- Threat intelligence sectorial. Que custa caro e tem aprendizagem-curve.
- Processo, runbooks, playbooks. 6 a 12 meses para amadurecer.
O custo total de propriedade (TCO) para um SOC interno funcional ronda €500k–€1M/ano para uma PME com 100–250 trabalhadores. É inviável para a maioria.
A alternativa é MSSP. Um MSSP com SOC dedicado e equipa de hunters distribui esses custos por dezenas de clientes, conseguindo entregar a mesma capacidade por €1.500–€8.000/mês — uma fracção do custo. A perda real é uma camada de abstração: os hunters não conhecem a sua organização tão bem como uma equipa interna conheceria, e dependem de boa comunicação e onboarding sólido para serem efectivos.
O modelo híbrido — equipa interna pequena (1-2 pessoas em horário útil) + MSSP em 24/7 e cobertura de hunting avançado — tende a ser o melhor compromisso para PMEs com 100–500 trabalhadores em sectores regulados.
Threat hunting + NIS2: que controlos satisfaz
Para PMEs sujeitas à NIS2, threat hunting contribui directamente para a conformidade com vários controlos do Artigo 27:
- Controlo 2 (gestão de incidentes): hunting acelera detecção e responsabiliza-se por reduzir o tempo até notificação ao CNCS dentro do prazo de 24 horas.
- Controlo 6 (segurança de rede e monitorização): hunting é a forma activa deste controlo; satisfaz o requisito implícito de "monitorização contínua" no nível "Substancial".
- Controlo 9 (gestão de vulnerabilidades): hunting frequentemente descobre vulnerabilidades já exploradas que scanners não detectaram.
Não é juridicamente obrigatório implementar threat hunting per se — é opcional escolher como satisfazer estes controlos. Mas para EE em sectores críticos, é a forma mais defensável e a que melhor demonstra "due care" perante o CNCS num cenário pós-incidente.
Como começar sem montar um SOC interno
Para uma PME que decide avançar:
- Faça um inventário honesto. Que sistemas críticos? Que dados de alto valor? Que tooling existe (EDR, SIEM, logs centralizados)? Sem isto, hunting não tem base.
- Escolha um MSSP com hunters reais. Há diferença real entre MSSPs que só fazem alert triage e os que têm capacidade de hunting estruturada. Pergunte: "Qual foi o último ataque sofisticado que detectaram via hunting que não veio de alerta automático?"
- Defina o âmbito inicial. Hunting em todos os endpoints + servidores críticos é um bom ponto de partida. Adicione cloud workloads e identidade no segundo trimestre.
- Estabeleça métricas de baseline. Meça MTTD e dwell time desde o dia 1. Sem baseline não há melhoria mensurável.
- Onboarding de 4-8 semanas. Os hunters precisam de aprender a sua rede, identificar sistemas críticos, mapear utilizadores VIP, entender padrões normais antes de poderem detectar anómalos.
- Revisão trimestral. Os hunting use cases evoluem com o panorama de ameaças. Reúna-se com o MSSP de 3 em 3 meses para rever hipóteses, métricas, e ajustes.
Threat hunting bem implementado paga-se a si próprio na primeira detecção significativa. O retorno raramente é evidente em mês 1 — torna-se óbvio quando, em mês 6 ou 9, um incidente é apanhado em dias quando teria demorado meses.
Próximos passos:
- SIEM gerido vs SIEM próprio: TCO em 3 anos
- SOC 24/7: in-house, MSSP, ou híbrido
- Marcar Assessment NIS2 e demo PRO