Adversary Behaviour / IOCs20. Juli 2026 · 5 Min. Lesezeit

TTPs vs. IOCs: Warum du auf Verhalten, nicht auf Hashes setzen solltest

Einleitung

Wenn deine Detection-Strategie aus geblockten Hashes und IP-Listen besteht, bist du dem Angreifer immer einen Schritt hinterher. IOCs sind flüchtig – TTPs (Tactics, Techniques, Procedures) sind das stabile Verhalten dahinter. Dieser Artikel erklärt den Unterschied, warum die Verschiebung in Richtung TTP-Detection für KMU realistisch ist und wie du anfängst.

Warum das Thema wichtig ist

Threat-Intelligence-Feeds liefern täglich neue IOCs: Hash-Werte, IP-Adressen, Domain-Listen. Eingespielt ins SIEM oder in die Firewall, fühlt sich das nach Schutz an. Das Problem: Ein Angreifer ändert einen Hash in Sekunden. Eine IP wechselt mit jedem neuen Server. Eine Domain wird mit DGA-Algorithmen täglich neu generiert. Wer nur auf IOCs detektiert, jagt einer Schimäre hinterher – und ist im Schnitt 24–72 Stunden zu spät. Verhalten dagegen lässt sich nicht trivial ändern. Wenn ein Angreifer LSASS dumpt, sieht das immer ähnlich aus – egal welches Tool er nutzt.

Die Pyramid of Pain

David Bianco hat das Konzept 2013 in seiner „Pyramid of Pain“ auf den Punkt gebracht. Die Pyramide beschreibt, wie viel Aufwand es einem Angreifer kostet, einen Detection-Indikator zu umgehen.

                                ┌──────────┐
                                │   TTPs   │  ← extrem hoch (Verhalten ändern)
                              ┌─┴──────────┴─┐
                              │     Tools    │  ← hoch (neue Tools entwickeln)
                            ┌─┴──────────────┴─┐
                            │  Network/Host    │  ← mittel
                            │   Artefacts      │
                          ┌─┴──────────────────┴─┐
                          │   Domain Names       │  ← einfach (umregistrieren)
                        ┌─┴──────────────────────┴─┐
                        │      IP Addresses        │  ← trivial (DHCP/Cloud)
                      ┌─┴──────────────────────────┴─┐
                      │       Hash Values            │  ← trivial (1 Bit ändern)
                      └──────────────────────────────┘

Je höher in der Pyramide deine Detection ansetzt, desto mehr Schmerzen verursachst du dem Angreifer.

IOC vs. TTP – konkret

IOC-Beispiel (Hash)

SHA256: 7d4f9e8a3b2c1d6f5e4a3b2c1d6f5e4a3b2c1d6f5e4a3b2c1d6f5e4a3b2c1d6f
Datei:  invoice.exe

Der Angreifer kompiliert die Malware mit anderem Padding neu → neuer Hash → deine Detection ist tot.

TTP-Beispiel (Verhalten)

T1003.001 – OS Credential Dumping: LSASS Memory
Verhalten: Ein Prozess (oft non-system, oft mit interaktivem Login)
           öffnet einen Handle auf lsass.exe mit
           PROCESS_VM_READ-Permission und liest dessen Memory.

Egal ob mimikatz, ProcDump, Cobalt Strike oder ein selbstgeschriebenes Tool: das Verhalten ist gleich. Ein Sysmon-Event 10 mit TargetImage=lsass.exe und ungewöhnlichem GrantedAccess-Wert detektiert sie alle.

MITRE ATT&CK als gemeinsames Vokabular

MITRE ATT&CK (Adversarial Tactics, Techniques & Common Knowledge) ist die Standard-Taxonomie für TTPs. Die Matrix ist gegliedert in:

Praktischer Wert für KMU:

  1. Detection-Coverage messen: Welche Techniken deckst du ab? Der ATT&CK Navigator visualisiert das.
  2. Threat-Intel verständlich machen: Reports von Mandiant, CrowdStrike, BSI nutzen ATT&CK-IDs.
  3. Detection-Engineering strukturieren: Statt zufälliger Rules baust du Coverage gezielt aus.

TTP-Detection in der Praxis

Beispiel 1: Persistence via Scheduled Task (T1053.005)

Verhalten: Ein neuer geplanter Task wird angelegt, der bei jedem Boot oder Login läuft.

Detection (Windows Event 4698 oder Sysmon 1 mit schtasks.exe):

title: New Scheduled Task Created via schtasks
detection:
  selection:
    EventID: 4688
    NewProcessName|endswith: '\schtasks.exe'
    CommandLine|contains:
      - '/Create'
      - '/sc onlogon'
      - '/sc onstart'
  filter:
    User|startswith: 'NT AUTHORITY\SYSTEM'
  condition: selection and not filter

Detektiert jeden Angreifer, der per schtasks.exe Persistence baut – egal welches Tool er nutzt.

Beispiel 2: LSASS Access (T1003.001)

Detection via Sysmon Event 10:

title: LSASS Access from suspicious process
detection:
  selection:
    EventID: 10
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      - '0x1010'      # PROCESS_VM_READ + PROCESS_QUERY_INFORMATION
      - '0x1410'
      - '0x1438'
  filter:
    SourceImage|endswith:
      - '\MsMpEng.exe'
      - '\svchost.exe'
  condition: selection and not filter

Detektiert mimikatz, ProcDump, comsvcs.dll und alle gängigen LSASS-Dump-Tools über das gleiche Verhaltensmuster.

Beispiel 3: Living-off-the-Land via certutil (T1140 / T1105)

Verhalten: Angreifer nutzt certutil.exe als Downloader, weil es signiert ist und wenig Verdacht erregt.

title: Certutil Download
detection:
  selection:
    EventID: 4688
    NewProcessName|endswith: '\certutil.exe'
    CommandLine|contains:
      - '-urlcache'
      - '-f'
      - 'http'
  condition: selection

IOCs sind nicht wertlos

Klares Statement: IOCs haben weiterhin einen Platz – aber den richtigen.

Wo IOCs glänzen:

Wo IOCs versagen:

Faustregel: IOCs als Zusatz, TTPs als Fundament.

Wo du Threat-Intel mit TTPs bekommst

Der Weg von IOC zu TTP – ein Migrations-Plan

Monat 1: Sichtbarkeit schaffen

Monat 2: Erste TTP-Detections

Monat 3: Coverage messen

Laufend: IOCs als Ergänzung

Praxis-Checkliste

Fazit

IOCs verbrennst du in 24 Stunden. TTPs halten Jahre. Wer Detection ernsthaft betreiben will, baut sie auf Verhalten – nicht auf Listen. Für KMU ist das machbar: Mit Sysmon, ATT&CK und SIGMA-Rules aus dem Public-Repo bekommst du eine Detection-Grundlage, die dem Angreifer ernsthaft wehtut. IOCs sind das Sahnehäubchen, nicht die Torte.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete TTP-Detections, Threat-Intel-Highlights und Coverage-Strategien. Trag dich ein.

← Zurück zur Übersicht