Skip to content
Vigil Security
Threat Hunting

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

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:

  1. 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.
  2. 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?"
  3. 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.
  4. Estabeleça métricas de baseline. Meça MTTD e dwell time desde o dia 1. Sem baseline não há melhoria mensurável.
  5. 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.
  6. 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:

Simão Ribeiro

Fundador da Vigil Security. SOC 24/7, threat hunting e conformidade NIS2 para PMEs portuguesas.