Network Detection and Response (NDR): Bedrohungserkennung im Netzwerk

Network Detection and Response (NDR) ist eine Sicherheitskategorie die Netzwerkverkehr in Echtzeit analysiert um Angriffe zu erkennen die Endpoint-Schutzlösungen umgehen. Während EDR (Endpoint Detection and Response) den einzelnen Rechner überwacht, sieht NDR den gesamten Netzwerkverkehr - und erkennt damit Angriffsmuster die keine Malware auf Endpoints erfordern (Living-off-the-Land, Pass-the-Hash, laterale Bewegung über legitime Protokolle).

Warum NDR neben EDR?

Erkennungslücken von Endpoint-Lösungen:

  Angreifer-Technik:         EDR erkennt?  NDR erkennt?
  ─────────────────────────────────────────────────────
  Malware auf Endpoint        ✓ ja          ○ indirekt
  Fileless-Malware (LOL)      ○ manchmal    ✓ via Netzwerk
  Pass-the-Hash (kein Malware) ✗ selten     ✓ NTLM-Muster
  Lateral Movement (WMI)      ○ manchmal    ✓ Protokoll-Analyse
  C2 über HTTPS               ✗ schwer      ✓ JA3-Fingerprint, Timing
  DNS-Tunneling               ✗ selten      ✓ DNS-Traffic-Analyse
  Daten-Exfiltration          ○ manchmal    ✓ Volume + Destination
  Kompromittiertes IoT-Gerät  ✗ kein Agent  ✓ Netzwerkverhalten
  BYOD ohne EDR               ✗ kein Agent  ✓ Netzwerkverhalten
  Insider-Threat              ✗ schwer      ✓ Verhaltensbaseline

  → NDR deckt blinde Flecken ab die EDR strukturell nicht sehen kann
  → Optimal: EDR + NDR + SIEM (XDR-Ansatz)

NDR-Architektur und Datenquellen

NDR-Deployment-Architektur:

Datenquellen:

  1. Raw Packet Capture (PCAP):
     → Vollständige Paket-Analyse inkl. Payload
     → Höchste Erkennungstiefe
     → Hoher Speicherbedarf (meist nur Last 24-48h)
     → Idealfall: Taps auf Core-Switches und Internet-Gateway

  2. NetFlow/IPFIX/sFlow:
     → Nur Metadaten (IP, Port, Bytes, Pakete, Zeitstempel)
     → Kein Payload → Datenschutzfreundlicher
     → Skaliert auf sehr große Netzwerke
     → Kommt von: Switches/Router (Cisco, Juniper), Cloud (AWS VPC Flow Logs)

  3. Network-Sensor/SPAN-Port:
     → Kopie des Netzwerkverkehrs an Sensor
     → Passiv (kein Einfluss auf Netzwerk)
     → Sensor analysiert Traffic und korreliert

  Deployment-Punkte:
    ┌─────────────────────────────────────────┐
    │  Internet ── Firewall ── [NDR-Sensor] ─┤ Nord-Süd Traffic
    │                                         │
    │  [NDR-Sensor] ── Core-Switch ──────────┤ Ost-West Traffic (LM!)
    │                          │              │
    │                   Server | Endpoints    │
    └─────────────────────────────────────────┘
  → Ost-West-Traffic (intern) oft wichtiger als Nord-Süd!
  → Lateral Movement läuft intern → ohne internen Sensor blind!

Erkennungsmethoden

Erkennungs-Engine-Typen:

1. Signaturbasierte Erkennung:
   → Bekannte Malware-Netzwerkmuster (Suricata IDS-Rules, Snort-Rules)
   → C2-IP/Domain-Listen (Threat Intelligence Feeds)
   → Malware-spezifische Payload-Patterns
   → Niedrige False-Positive-Rate, aber blind für unbekannte Bedrohungen

2. Machine-Learning und Verhaltensanalyse:
   → Baseline: normales Verhalten lernen (14-30 Tage)
   → Anomalie-Erkennung: was weicht von der Norm ab?

   Beispiele:
   a) Beaconing-Erkennung:
      → C2-Malware sendet regelmäßige Check-ins
      → Analyse: regelmäßige Verbindungen zu gleicher IP/Domain?
      → Periodiziät erkennen (z.B. alle 3600 Sekunden ±Jitter)

   b) DNS-Tunneling:
      → Legale DNS-Anfragen: kurz, an bekannte Domains
      → DNS-Tunnel: sehr lange Subdomain-Namen, unbekannte TLDs
      → NDR: Statistik auf DNS-Label-Länge, Entropy, Query-Rate

   c) Lateral Movement:
      → Ungewöhnliche SMB/WMI-Verbindungen zwischen Workstations
      → Normales Verhalten: Workstation → Server, nicht Workstation → Workstation
      → NDR: Neue Verbindungspaare, ungewöhnliche Tageszeiten

3. JA3/JA3S TLS-Fingerprinting:
   → TLS-Handshake enthält Client-Hello (Cipher-Suiten, Extensions)
   → MD5-Hash davon = JA3-Fingerprint
   → Malware-Familien haben charakteristische JA3-Fingerprints
   → Cobalt Strike Beacon: bestimmter JA3-Hash bekannt
   → Erkennung auch wenn Traffic verschlüsselt ist!

4. JARM (Aktives TLS-Fingerprinting):
   → Server antwortet auf TLS-Probes charakteristisch
   → C2-Server haben bestimmte JARM-Fingerprints (Metasploit, Cobalt Strike)
   → NDR kann bekannte C2-Framework-Fingerprints blocken

Konkrete Bedrohungsszenarien

NDR-Erkennung in der Praxis:

Szenario 1 - Cobalt Strike C2:

  Angreifer: Cobalt Strike Beacon auf kompromittiertem Workstation
  Traffic:   HTTPS zu 185.x.x.x (externe IP)
  EDR:       Erkennt Beacon möglicherweise nicht (LOL-Techniken, Reflective DLL)

  NDR erkennt:
  → JA3-Fingerprint des Beacons (bekannt aus Threat Intelligence)
  → Beaconing-Verhalten: HTTPS-Verbindung alle 60s ± 30s Jitter
  → Destination-IP nicht in Whitelist, Geo: verdächtig
  → Volume: gering, aber konsistent (typisch für C2)

  Alert: "Possible C2 Beaconing from Workstation-1 to 185.x.x.x"
  Confidence: High (JA3 + Timing-Pattern + Threat-Intel)

Szenario 2 - Lateral Movement via Pass-the-Hash:

  Angreifer hat Hash eines Domain-Admin (Mimikatz)
  Verbindungen: Workstation-1 → 10.0.0.x/24 via SMB/WMI
  EDR auf Workstation-1: Mimikatz war dateilos (Reflective Load)

  NDR erkennt:
  → Workstation-1 verbindet sich zu 47 Hosts in 10 Minuten (Port 445/SMB)
  → Neue Verbindungspaare: WS-1→WS-2, WS-1→WS-3 (ungewöhnlich!)
  → NTLM-Authentifizierungen von einem Host zu vielen → verdächtig

  Alert: "Lateral Movement - SMB Scanning from Workstation-1"
  Confidence: High (volume + new connections + NTLM pattern)

Szenario 3 - DNS-Exfiltration:

  Angreifer nutzt DNS-Tunnel für Daten-Exfiltration:
  Traffic: DNS-Anfragen für sehr lange Subdomains
  z.B.: dGhpcyBpcyBzZW5zaXRpdmUgZGF0YQ.exfil.attacker.com

  NDR erkennt:
  → DNS-Label-Länge weit über Durchschnitt (>50 Zeichen)
  → Hohe Entropy der Subdomains (Base64-codierter Content)
  → Unbekannte Domain (nicht in DNS-Whitelist)
  → Query-Rate: 1 Query/Sekunde (untypisch für normale DNS-Nutzung)

  Alert: "Possible DNS Tunneling from 10.0.1.15 to exfil.attacker.com"
  Confidence: High

Szenario 4 - Kompromittiertes IoT-Gerät:

  Kamera im Netzwerk sendet Traffic an externe IP
  Kein EDR auf IoT-Geräten möglich

  NDR erkennt:
  → Kamera verbindet zu 1.2.3.4 (kein legitimer Cloud-Service)
  → Volume: 50 MB/h Upload (ungewöhnlich für interne Kamera)
  → Port 4444 (bekannter Metasploit-Default-Port)

  Alert: "IoT Device Anomalous Outbound - Possible Backdoor"

NDR-Lösungen im Vergleich

Marktübersicht NDR-Lösungen (2024):

Enterprise-Lösungen:
  Darktrace:
  → AI-Ansatz ("Self-Learning AI", kämpft aktiv gegen Angriffe)
  → Autonomous Response (RESPOND): blockiert automatisch
  → Stärken: Anomalie-Erkennung, Cloud-Variante
  → Schwächen: hohe False-Positive-Rate am Anfang, teuer

  ExtraHop Reveal(x):
  → L7-Protokoll-Analyse (Dekodierung von 70+ Protokollen)
  → Starke NDR + Packet-Analytics-Kombination
  → Gut für Ost-West-Traffic-Analyse im Rechenzentrum

  Vectra AI (Cognito):
  → KI-fokussierter Ansatz, AWS/Azure-Cloud-Support
  → Integration mit Microsoft Defender, CrowdStrike
  → Stärken: wenig False Positives, gute Priorisierung

  Cisco Secure Network Analytics (Stealthwatch):
  → NetFlow-basiert, skaliert auf sehr große Netzwerke
  → Gut für ISP-Umgebungen und Multi-Location
  → Native Integration in Cisco-Infrastruktur

Open-Source / SMB-Lösungen:
  Zeek (ehem. Bro):
  → Framework für Netzwerkanalyse (keine Out-of-the-Box-GUI)
  → Basis für viele kommerzielle Lösungen
  → Skript-basiertes Detection Framework
  → kostenlos, sehr flexibel, hoher Aufwand für Betrieb

  Suricata + Elastic Stack:
  → IDS/IPS + SIEM-Kombination
  → Elasticsearch, Kibana für Visualisierung
  → Gut für Technical Teams mit Ressourcen

  SELKS (Stamus Networks):
  → Suricata + Elastic + Kibana vorkonfiguriert
  → Community-Edition kostenlos
  → Schneller Einstieg für kleinere Teams

NDR in XDR-Plattformen

NDR als Teil von XDR (Extended Detection and Response):

XDR = EDR + NDR + Cloud Security + Email Security + Identity

Microsoft Sentinel (SIEM) + Microsoft Defender for Network (NDR):

• Traffic Analytics aus Azure VPC Flows
• Network Watcher für Azure-Ressourcen
• Integration mit Defender for Endpoint (Korrelation)

CrowdStrike Falcon + Falcon LogScale (NDR):

• Falcon Network Detection: NDR-Komponente
• Korrelation: Endpoint + Netzwerk → bessere Angriffskette

Palo Alto Networks Cortex XDR:

• Network Threat Intelligence + EDR
• Netzwerk-Sensoren (physical und virtual)

NDR → SOAR Automation:

Alert: “Beaconing von Workstation-47” → SOAR-Playbook:

1. EDR: Workstation-47 isolieren (automatisch!)
2. Ticket erstellen (Jira/ServiceNow)
3. Analyst-Alert (PagerDuty)
4. Netzwerk: IP in Firewall blocken
5. Enrichment: Reputation-Lookup der C2-IP
6. Timeline: alle anderen Verbindungen von WS-47 der letzten 7 Tage

Implementierungs-Roadmap

NDR-Einführung: Schritt-für-Schritt:

Phase 1 (Woche 1-2): Baseline
  □ Sensor platzieren (SPAN-Port am Core-Switch)
  □ NetFlow von Firewall/Router aktivieren
  □ Lernphase: 14-30 Tage normalen Traffic aufzeichnen
  □ Erste Alerts kategorisieren (FP vs. TP)

Phase 2 (Woche 3-4): Tuning
  □ False Positives identifizieren und ausschließen
  □ Whitelists: bekannte legitime Services, Update-Server
  □ Threshold-Anpassung: wann wird ein Alert ausgelöst?
  □ First Responder definieren: wer bearbeitet NDR-Alerts?

Phase 3 (Woche 5-8): Integration
  □ NDR → SIEM (Alerts forwarden, Korrelation)
  □ Threat Intelligence Feeds einbinden (MISP, commercial TI)
  □ NDR → SOAR (automatische Response-Aktionen)
  □ Runbooks/Playbooks für häufige Alert-Typen

Phase 4: Ongoing
  □ Wöchentliches Alert-Review
  □ Threat-Hunting: aktiv nach NDR-Daten suchen
  □ Coverage-Review: neue Netzwerksegmente abdecken?
  □ Quartallicher NDR-Health-Check (False-Positive-Rate, Alert-Volume)