SIEM Rules & Detection31. Juli 2026 · 7 Min. Lesezeit

IOC-Detection: Was taugt wirklich – Hashes, IPs, Domains?

Einleitung

Threat-Intelligence-Feeds liefern täglich Tausende von IOCs: Datei-Hashes, IP-Adressen, Domains, URLs. Das klingt nach fertiger Detection. In der Praxis sieht es anders aus: ein SHA256-Hash wird vom Angreifer in Sekunden geändert, eine IP-Adresse ist in 24 Stunden gewechselt, und eine Domain kann auf einem CDN liegen, das auch legitime Dienste hostet. Dieser Artikel erklärt, welchen Wert verschiedene IOC-Typen wirklich haben, warum das „Pyramid of Pain“-Framework die richtige mentale Landkarte ist, und wie du IOC-Detection sinnvoll in dein SIEM integrierst – ohne in Alert-Fatigue zu ertrinken.

Warum das Thema wichtig ist

IOC-basierte Detection ist der älteste Ansatz in der Security – und gleichzeitig der am schwersten misszuverstehende. Viele Teams verbringen enorme Energie damit, Millionen von IP-Blocklisten zu pflegen und fragen sich, warum ihre Detection-Rate trotzdem miserabel ist. Das liegt an einem Grundproblem: IOCs auf der untersten Ebene (Hashes, IPs) sind trivial für Angreifer zu ändern und veralten innerhalb von Stunden bis Tagen. Wer nur auf IOCs setzt, kämpft immer gegen die letzte bekannte Angriffsversion – nicht gegen die nächste.

Gleichzeitig haben IOCs ihren Platz: für Forensik, für Malware-Triage und für die Erkennung bekannter, schlecht ausgestatteter Akteure (Commodity-Malware) sind sie wertvoll. Der Fehler ist, sie für alles zu verwenden.

Das Pyramid of Pain

David Bianco beschrieb 2013 das „Pyramid of Pain“-Framework: je höher im Modell, desto schwerer ist es für Angreifer, diese Indicator-Klasse zu ändern, und desto wertvoller ist die Detection.

         ┌─────────────────────────┐
         │      TTPs               │  Schwer zu ändern → hoher Wert
         ├─────────────────────────┤
         │  Tools                  │
         ├─────────────────────────┤
         │  Network / Host Artifacts│
         ├─────────────────────────┤
         │  Domain Names           │
         ├─────────────────────────┤
         │  IP Addresses           │
         ├─────────────────────────┤
         │  Hash Values            │  Trivial zu ändern → niedriger Wert
         └─────────────────────────┘

Fazit der Pyramide: investiere die meiste Detection-Energie in TTPs und Artifacts, nicht in Hashes und IPs.

IOC-Typ 1: Datei-Hashes (MD5, SHA1, SHA256)

Wert

Sehr niedrig für proaktive Detection. Hoch für Forensik und Malware-Triage.

Problem

Ein Angreifer ändert eine Byte im Binär: neuer Hash. Das dauert Sekunden. Polymorphe Malware und gepackte Payloads erzeugen bei jedem Lauf andere Hashes (Metamorphism).

Wann trotzdem sinnvoll

SIEM-Integration

Hash-Listen in Wazuh als CDB-Listen:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<rule id="100010" level="15">
  <if_sid>92200</if_sid>
  <list field="win.eventdata.hashes" lookup="match_key">etc/lists/known_bad_hashes</list>
  <description>Known malware hash detected: $(win.eventdata.hashes)</description>
  <group>malware,ioc</group>
</rule>

CDB-Liste (/var/ossec/etc/lists/known_bad_hashes):

44d88612fea8a8f36de82e1278abb02f:
275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f:

Refresh-Frequenz: täglich, aus MalwareBazaar-Feed oder MISP.

IOC-Typ 2: IP-Adressen

Wert

Niedrig bis mittel. Nützlich für Command-and-Control-Erkennung, fast wertlos für Endpoint-Detection.

Problem

C2-Infrastruktur wechselt in 24–48 Stunden. VPNs, Tor-Exit-Nodes und kompromittierte legitime Hosts maskieren die tatsächliche Angreifer-IP. IP-Blocklisten haben notorisch hohe False-Positive-Raten: Cloudflare, Fastly, AWS-IP-Ranges sind in vielen Listen – und auch in jedem legitimen CDN-Traffic.

Wann sinnvoll

SIEM-Integration

# SIGMA-Rule: Auth-Event aus bekanntem Hosting-AS
title: Authentication from Datacenter AS (Possible VPN/Proxy/C2)
status: experimental
logsource:
  category: authentication
detection:
  selection:
    EventID: 4624
    IpAddress|cidr:
      - '104.21.0.0/16'   # Cloudflare Workers (oft für C2 genutzt)
      - '198.41.128.0/17' # Cloudflare
  filter_legit:
    IpAddress|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
  condition: selection and not filter_legit
level: low

Wichtig: als Enrichment-Signal verwenden, nicht als isolierten Alert. IP-Alert + ungewöhnliche Tageszeit + neuer User = verdächtig.

IOC-Typ 3: Domain Names

Wert

Mittel. Höhere Halbwertszeit als IPs (Domains kosten Geld und Zeit), aber immer noch begrenzt.

Problem

Domain-Fronting und CDN-Hosting: eine C2-Domain zeigt auf Cloudflare-IP, die auch legitime Seiten hostet. IP-Block hilft nicht, nur DNS-basierte Detection. Außerdem: DGA (Domain Generation Algorithms) erzeugen täglich Tausende neue Domains.

Wann sinnvoll

SIGMA-Rule für NX-Domain-Spike

title: DNS NXDOMAIN Spike (Possible DGA Activity)
logsource:
  category: dns
detection:
  selection:
    dns.response_code: NXDOMAIN
  timeframe: 1m
  condition: selection | count() > 50
level: medium

DNS-RPZ Setup (BIND9)

# named.conf.options
response-policy { zone "rpz.local"; };

# /etc/bind/db.rpz.local
$ORIGIN rpz.local.
; C2-Domains aus Feed
malware-c2.example.com  CNAME  .   ; blocken + NXDOMAIN zurück

Automatischer RPZ-Update via cron aus URLhaus/ThreatFox:

#!/bin/bash
curl -s "https://urlhaus-api.abuse.ch/v1/urls/recent/limit/1000/" \
  | jq -r '.urls[].url_host' | sort -u > /tmp/new_domains.txt
# Domains in RPZ-Format konvertieren und zone neu laden

IOC-Typ 4: Artifacts (Registry, Dateipfade, Mutex)

Wert

Mittel bis hoch. Schwerer zu ändern als Hashes/IPs, da Malware oft auf bestimmte Registry-Keys oder Pfade angewiesen ist.

Beispiele

Artifact-Typ Beispiel Technik
Registry-Key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\UpdateHelper T1547.001
Dateipfad %APPDATA%\WindowsUpdate.exe T1036
Mutex Global\{A1B2C3D4-...} Malware-Fingerprint
Named Pipe \pipe\msagent_a Cobalt-Strike-Beacon

Sysmon-Detection für verdächtige Registry-Keys

title: Suspicious Registry Run Key – Non-Standard Location
logsource:
  product: windows
  category: registry_set
detection:
  selection:
    EventID: 13
    TargetObject|contains:
      - '\CurrentVersion\Run'
      - '\CurrentVersion\RunOnce'
  filter_legit:
    Image|endswith:
      - '\OneDrive.exe'
      - '\Teams.exe'
      - '\Slack.exe'
  filter_path:
    Details|startswith:
      - 'C:\Program Files\'
      - 'C:\Program Files (x86)\'
  condition: selection and not 1 of filter_*
level: medium

IOC-Typ 5: TTPs (Techniken und Taktiken)

Wert

Hoch. TTPs sind das Verhalten des Angreifers, nicht die konkreten Tools oder Infrastruktur. Selbst wenn der Angreifer Hash, IP und Domain wechselt – er bleibt lateral Movement, er nutzt LSASS-Dump, er installiert persistente Services.

TTP-Detection = SIGMA-Rules auf Verhaltens-Ebene. Dieser Artikel behandelt IOC-Detection, TTP-Detection ist Thema des SIGMA-Artikels und des Lateral-Movement-Artikels.

IOC-Management: Kein Feed-Hoarding

50 Threat-Intel-Feeds zu abonnieren macht die Detection nicht besser. Mehr Feeds bedeuten:

Empfehlung für KMU: 3–5 hochwertige, aktuelle Feeds reichen:

Feed Typ Qualität Format
ThreatFox (abuse.ch) C2-IPs, Domains, Hashes hoch, kurze TTL JSON, CSV
URLhaus (abuse.ch) Malware-URLs hoch CSV, MISP
MalwareBazaar (abuse.ch) Datei-Hashes hoch JSON
OpenCTI (intern) Eigene Aggregation variabel STIX/TAXII
AbuseIPDB IP-Reputation mittel API

Feeds mit TTL tracken: IOCs nach 7–14 Tagen automatisch aus dem aktiven Set entfernen, sofern keine Reaktivierung durch anderen Feed.

IOC-Detection-Strategie für KMU

1. Datei-Hashes:    → Forensik/Triage (VirusTotal), nicht primäre Detection
2. IPs:             → DNS-RPZ + Auth-Anomalie-Enrichment (nicht Block-Reflex)
3. Domains:         → DNS-RPZ + NX-Domain-Monitoring
4. Artifacts:       → Sysmon-Registry/Process-Rules (hoher Wert)
5. TTPs:            → SIGMA-Rules für Verhalten (primäre Detection)

IOCs + TTPs kombiniert: wenn ein Host eine bekannte C2-Domain anfragt UND kurz danach ein cmd.exe von wsmprovhost.exe spawnt – das ist ein sehr starkes Signal.

Stolperfallen

Praxis-Checkliste

Fazit

IOC-Detection ist kein Ersatz für TTP-basierte Detection – aber ein sinnvolles Ergänzungsschicht. Hashes und IPs haben kurze Halbwertszeiten und niedrige Eigenständigkeit; Domains, Artifacts und TTPs bringen echten Mehrwert. Wer 50 Threat-Intel-Feeds sammelt und glaubt, damit gut geschützt zu sein, irrt: die Energie sollte stattdessen in solide SIGMA-Rules auf Verhaltens-Ebene fließen. IOCs als Forensik-Tool, DNS-RPZ für Domain-Blocking, NX-Domain-Monitoring für DGA – das ist die pragmatische IOC-Strategie für KMU.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete IOC-Feed-Integrationen, DNS-RPZ-Konfigurationen und IOC-TTL-Management-Skripte für KMU. Trag dich ein.

← Zurück zur Übersicht