Threat hunting in Switzerland: when detection rules stop being enough

Threat hunting is the hypothesis-driven search for adversaries that slip past existing detection rules. It complements SIEM and EDR alerts, it does not replace them. The goal is to structurally reduce how long adversaries stay undetected; Mandiant M-Trends 2026 reports a median of 14 days. Analysts actively search for tactics, techniques and procedures (TTPs) before an alert fires.

All

How this compares to neighbouring topics

Threat hunting looks for adversaries that may already be inside the network. Attack surface management reduces the exposed footprint so fewer attackers get a foothold in the first place. Penetration testing and red team assessments simulate attacks at specific points for limited periods. Threat hunting is a continuous SOC discipline, not a project.

Why detection rules alone are not enough

Detection content covers known patterns. Attackers know this and deliberately operate inside the tolerances that keep rules silent. Living-off-the-land, legitimate admin tools and slow off-hours activity are designed to stay under the alerting threshold. Threat hunting accepts this reality and starts with a hypothesis.

Core principle

Alerting asks: what just happened? Threat hunting asks: where would I hide if I were inside, and how do I prove nobody is there?

The hunt model: hypothesis, data, evidence

  1. Formulate a hypothesis backed by threat intelligence, MITRE ATT&CK TTPs or environment-specific context (for example, newly approved SaaS access, a merger, layoffs).
  2. Check the data basis: are the log sources complete, are retention and field coverage sufficient, where are the blind spots?
  3. Run the search: queries in the SIEM/XDR, EDR telemetry, identity and cloud audit logs. The outcome is a confirmed finding, a refuted hypothesis or an identified data gap.
  4. Feed the finding back: a new detection rule, a change to existing content, a new log source or an awareness topic.
  5. Document the hypothesis, query, result and date. This provides evidence for ISO 27001 audits (A.5.27, A.8.16) and internal governance.

A realistic hunt backlog in the Swiss context

Hunt topicMITRE ATT&CK referenceWhy it matters in Switzerland
Token theft and session hijacking in M365/EntraT1550.004, T1539High M365 penetration in Swiss SMEs, MFA bypass is the real entry vector.
Business email compromise and mail-rule tamperingT1114, T1564.008Tied to Swiss payment flows and DE/EN/FR language switching.
Living-off-the-land: PowerShell, WMI, PsExec-like behaviourT1059.001, T1047, T1021.002Standard admin tooling on almost any Windows network, classically under-triggered.
OAuth app consent and unusual approvalsT1528Widespread as post-MFA persistence, often without an alert.
Unusual data exfiltration to cloud storageT1567.002revFADP (revised Federal Act on Data Protection) data categories in focus, notification thresholds can be triggered.
OT-adjacent anomalies in manufacturing environmentsT1210, T0886Swiss manufacturing SMEs with Purdue model and legacy systems.
Every hunt backlog needs environmental context. Topics lifted from generic literature without customer tailoring produce random findings.

What threat hunting measurably delivers

  • New or tightened detection rules per quarter, directly derived from hunts.
  • Identified and closed log gaps, tracked in the coverage register.
  • Reduction in the window during which an attacker could stay undetected (dwell time).
  • Evidence for ISO 27001 clause 10 (continual improvement) and Annex A controls A.5.27 and A.8.16.

Threat hunting without feedback into detection content is wasted time. Every hunt ends with one of three answers: a new rule, a closed data gap or a refuted hypothesis with a date. Anything else is a report without impact. For the underlying KPIs, see MTTD and MTTR.

Threat hunting anti-patterns

  • Hunts without a hypothesis: free-form rummaging in logs ends in alert fatigue and produces no reproducible results.
  • One-off hunts as a marketing exercise: one hunt report per year provides only a snapshot and fails to establish an ongoing discipline.
  • Hunts without a data basis: when key log sources are missing, searches produce false confidence.
  • Hunts without feedback: findings that do not flow into detection rules or log coverage will be missed again in the next attack.

Frequently asked questions

Is threat hunting the same as a penetration test?

A penetration test is a time-boxed, authorised attack from outside or inside aimed at finding vulnerabilities. Threat hunting is the continuous search for real adversaries that may already be inside the network. A penetration test is a project; hunting is a SOC discipline.

How often should hunts be run?

A realistic cadence for Swiss SMEs is two to four prioritised hunts per month, mixed between TTP-driven and environment-specific. Cadence matters less than feedback: every hunt ends with a new rule, a closed data gap or a refuted hypothesis.

Does threat hunting need dedicated tooling?

Threat hunting usually needs only SIEM, EDR and identity logs if log quality is sufficient. Additional tooling (Jupyter, notebook-based analysis, dedicated hunt platforms) helps at higher maturity with large data volumes but is optional.

How is threat hunting evidenced in an audit?

Maintain a hunt register with the date, hypothesis, query, data sources and result. Link each entry to the resulting detection rule changes. This covers ISO 27001 A.5.27 (learning from incidents), A.8.16 (monitoring) and clause 10 (continual improvement). For the wider framework, see [ISO 27001 and SOC](/en/soc/iso-27001-and-soc).

Does AI-assisted analysis replace manual threat hunting?

No, it shifts the focus. AI can propose anomalies and clusters and reduce analysts' workload. Hypothesis creation, environmental knowledge and judgement remain human responsibilities. Anyone who follows only model scores gets another source of alerts.

Continue reading in this cluster
MTTD and MTTR: the two SOC KPIs that count
Mean Time to Detect (MTTD) measures how fast a SOC spots an attack. Mean Time to Respond or Contain (MTTR, MTTC) measures how fast it is stopped. Together they are the only credible evidence that a SOC is working, not just running.
How a 24/7 SOC works in practice
A 24/7 SOC runs in overlapping analyst shifts with clear tiers, playbooks and an escalation matrix up to executive level. Alerts flow from EDR, identity, cloud and network into a central SIEM or XDR. They are triaged on L1, investigated on L2/L3 and never parked outside the customer tenant. Targets for critical cases: MTTR up to 60 minutes, MTTC between 1 and 4 hours.
Comparing SOC providers: the neutral selection checklist
Comparing SOC providers works via verifiable criteria, not logos: data scope, response authority inside the customer tenant, evidence artefacts, response times and contract wording. This page lists the questions used to line offers up side by side. Deliberately without vendor names, so the checklist holds up even when ANOMAL is not on the shortlist.
Penetration testing Switzerland: find attack surfaces before attackers do
A penetration test is a targeted attack simulation against defined systems, carried out by Swiss testers using a documented methodology. The test produces an auditable report with prioritised findings and recommendations that fit your environment. The report provides evidence for regulators and insurers. ANOMAL tests web, cloud, Active Directory, APIs and internal networks.
SOC as a Service in Switzerland: The Complete Guide
SOC as a Service is an externally operated Security Operations Center that monitors your environment around the clock, detects attacks and triggers the response. According to Mandiant M-Trends 2026, attackers went undetected for a median of 14 days in 2025. With a SOC that detects and assesses around the clock, typical detection time becomes much shorter.