MITM-Investigation-Playbook: Evidence auf L2, L3, L4 und L7

Ein MITM-Investigation-Playbook (Man-in-the-Middle) hilft, Verdachtsmomente strukturiert in belastbare Evidence zu übersetzen – und zwar so, dass Netzwerk-, SecOps- und IR-Teams eine gemeinsame Sprache haben. In modernen Unternehmensnetzen sind MITM-Szenarien nicht nur „klassisches“ ARP-Spoofing im LAN. Sie reichen von Layer-2-Manipulation (MAC-Move, Rogue Gateway), über Layer-3-Anomalien (asymmetrische Pfade, unerwartete Next-Hops), bis zu Layer-4-Indikatoren (Reset-/Retransmit-Spikes, Session-Rebinding) und Layer-7-Spuren (Header-Anomalien, Zertifikatswechsel, ungewöhnliche Redirects). Das Problem: Viele Untersuchungen scheitern nicht an fehlenden Tools, sondern an fehlender Korrelation. Ein sauberes Playbook definiert deshalb pro Schicht, welche Artefakte zu sichern sind, wie man sie zeitlich einordnet und wie man „harte Beweise“ von Rauschen trennt. Dieser Beitrag zeigt ein praxistaugliches Vorgehen, um Evidence auf L2, L3, L4 und L7 zu sammeln, zu verknüpfen und für Incident Response verwertbar zu machen – ohne Aktionismus und ohne sich in Einzelsymptomen zu verlieren.

Vorbereitung: Scope, Zeitfenster und Beweiskette festlegen

Bevor Sie Pakete mitschneiden oder Switch-Tabellen auslesen, definieren Sie drei Dinge: (1) den Scope (welche Systeme, welche VLANs, welche Services), (2) das Zeitfenster (Startpunkt des Verdachts, erwartete Dauer, bekannte Ereignisse) und (3) die Beweiskette (wer sammelt, wo wird gespeichert, wie wird Integrität sichergestellt). Gerade bei MITM-Verdacht ist es entscheidend, die Reihenfolge von Ereignissen nachvollziehbar zu halten.

• Case-ID und Incident-Timeline: ein eindeutiger Identifier, auf den alle Artefakte referenzieren.
• Zeitsynchronisation: prüfen, ob Sensoren, Switches, Firewalls, Server und SIEM auf UTC konsistent sind.
• Minimaler Datensatz: Welche Logs sind zwingend (DHCP, ARP/ND, Firewall-States, Proxy/WAF, Auth-Logs)?
• Integrität: Schreibschutz/Immutable Storage, Hashing der PCAPs und Export-Dateien.

Für generelle IR-Strukturen und Rollenmodelle ist NIST SP 800-61 (Computer Security Incident Handling Guide) eine nützliche Referenz, auch wenn Ihr Fokus hier auf Netzwerk-Evidence liegt.

MITM-Triage: Symptome einordnen, bevor Sie tief graben

Eine schnelle Triage verhindert, dass Sie Stunden in der falschen Schicht verbringen. Typische Auslöser sind Helpdesk-Meldungen („Zertifikatswarnung“, „Login hängt“), auffällige NDR-Signaturen (ARP-Spoofing, DHCP-Anomalien), SIEM-Korrelationen (gleiche IP mit wechselnder MAC) oder Performance-Indikatoren (RTT-Spikes, Retransmits). Ziel der Triage ist eine Hypothese, die Sie später beweisbar prüfen können.

• Symptomklasse: Vertraulichkeit (Datenabfluss), Integrität (Manipulation), Verfügbarkeit (Instabilität) oder Mischform.
• Betroffene Kommunikation: Ost-West (intern), Nord-Süd (extern), Remote Access (VPN/Proxy), Service-to-Service (mTLS).
• Erste Indikatoren: Zertifikatswechsel, ARP-Conflicts, ungewöhnliche Gateway-MAC, TCP-RST-Wellen, Redirect-Ketten.

Evidence auf Layer 2: ARP, MAC, VLAN und Switch-Realität

Layer 2 ist bei vielen MITM-Szenarien der Startpunkt, weil hier Adressauflösung und Weiterleitung stattfinden. Ein sauberer L2-Datensatz beantwortet: Welche MAC war wann wo? Welche IP war welcher MAC zugeordnet? Gab es Moves, Flaps oder Guard-Events? Wichtig ist, L2-Evidence nicht isoliert zu betrachten: Ein einzelner MAC-Move kann legitim sein (z. B. VM-Migration), die Häufung und Korrelation machen den Unterschied.

• CAM/MAC-Table Events: learned, moved, aged, cleared; inklusive Port und VLAN.
• ARP-Evidence: ARP-Requests/Replies, Gratuitous ARP, ARP-Conflicts (gleiche IP, andere MAC).
• STP-Events: Topology Change, Root Change, BPDU Guard/Root Guard Violations.
• Port-Security / 802.1X / NAC: Violation-Reason, Quarantine-Aktion, Auth-Status pro Port.
• LLDP/CDP Nachbarn: Unerwartete Nachbargeräte oder geänderte Chassis-IDs.

Konkrete L2-Prüffragen, die Evidence liefern

• Hat sich die Gateway-IP (Default Gateway) plötzlich auf eine neue MAC-Adresse aufgelöst?
• Gibt es Duplicate IP-Meldungen oder ARP-„Flapping“ zwischen zwei MACs?
• Zeigt der Switch, dass die verdächtige MAC auf mehreren Ports „wandert“ (MAC move count)?
• Wurden Schutzfunktionen ausgelöst (z. B. DHCP Snooping, DAI, BPDU Guard)?

Wenn Sie ARP auf Protokollebene sauber nachvollziehen möchten, hilft der Blick in RFC 826 (ARP). Für IPv6-Umgebungen ist Neighbor Discovery relevant; dort entstehen MITM-ähnliche Effekte über RA/ND-Spoofing.

Evidence auf Layer 3: Routing-Kontext, Pfade und Next-Hop-Anomalien

Auf Layer 3 geht es darum, ob Traffic „unerwartet“ geroutet wird. Ein MITM kann entstehen, wenn ein System als unerwünschter Transit agiert, ein falscher Next-Hop genutzt wird oder asymmetrische Pfade plötzlich auftreten. Besonders in komplexen Netzen mit VRFs, Policy-Based Routing, SD-WAN oder Cloud-Routing ist Layer 3 oft der Ort, an dem Fehlkonfiguration und Angriff ähnlich aussehen. Deshalb ist die Kombination aus Routing-Tabelle, Policy-Entscheidung und Flow-Telemetrie entscheidend.

• Routing-Table Snapshots: relevante Prefixes, Next-Hop, Administrative Distance/Metric, VRF/Tenant.
• ARP/ND-Gateway-Mapping (Übergang L2/L3): Welche MAC repräsentiert den Router-Interface wirklich?
• ACL/uRPF/Anti-Spoofing Logs: Drop-Reason (uRPF fail, martian, bogon) und Rule-ID.
• Traceroute/MTR Evidence: Pfadvergleich „gut“ vs. „verdächtig“ (mit Zeitstempel).
• NetFlow/IPFIX: ungewöhnliche Transit-Flows, neue „Hub“-Hosts, Traffic-Spikes zwischen Segmente.

Pfadabweichung messen, ohne sich von Einzelfällen täuschen zu lassen

Ein einzelner langsamer Hop ist kein Beweis. Sinnvoll ist, Baselines zu vergleichen: Median-RTT im Normalbetrieb vs. Incident-Zeitraum und die Streuung. Eine einfache Kennzahl ist die relative Abweichung:

$\mathrm{Deviation}=\frac{\mathrm{RTT} \mathrm{incident}–\mathrm{RTT} \mathrm{baseline}}{\mathrm{RTT} \mathrm{baseline}}$

Hohe Abweichungen können auf Umwege, zusätzliche Hops (z. B. Proxying/Intercept) oder Instabilität hindeuten. Erst in Kombination mit L2- und L4-Evidence wird daraus ein belastbarer Befund.

Für Best Practices gegen IP-Spoofing und fehlerhafte Quelladressen ist BCP 38 / RFC 2827 als Grundprinzip hilfreich, insbesondere wenn uRPF oder Ingress-Filtering Teil Ihrer Architektur ist.

Evidence auf Layer 4: TCP/UDP-Sessions, Resets, Retransmits und State

Layer 4 liefert häufig die ersten „harten“ technischen Signale für MITM-nahe Effekte: plötzliche TCP-Resets, auffällige Retransmit-Raten, ungewöhnliche Window-Patterns, oder Sessions, die scheinbar sauber starten, aber instabil werden. Wichtig: L4-Evidence kann auch durch Overload, Paketverlust oder MTU-Probleme entstehen. Deshalb müssen Sie die Daten so sammeln, dass Ursachen unterscheidbar bleiben.

• Firewall/Load-Balancer Session Logs: session_start, session_end, state_reason, bytes/packets, policy_rule_id.
• TCP-Flag Evidence: Häufung von RST, ungewöhnliche FIN/RST-Sequenzen, SYN-Retries.
• Retransmits & RTT: Retransmit-Spikes, stark schwankende RTT, Out-of-Order-Pakete.
• Port-/Service-Korrelation: Betroffene Zielports, neue Zielports, ungewöhnliche Seiteneffekte.
• PCAP an strategischen Punkten: idealerweise gleichzeitig an Client-Nähe und Server-Nähe (oder vor/nach Firewall).

Packet Capture: Wo schneiden, damit MITM nicht „unsichtbar“ bleibt?

Ein MITM ist oft nur dann beweisbar, wenn Sie Traffic an mehr als einem Punkt sehen. Ein einzelner Capture-Punkt kann eine Manipulation verschleiern, weil Sie nicht wissen, was vorher war. Sinnvoll ist ein Minimum aus zwei Perspektiven:

• Client-seitig: nahe am betroffenen Host oder Access-Switch (zeigt „was der Client sieht“).
• Server-seitig: nahe am Zielsystem oder Server-Segment (zeigt „was wirklich ankommt“).
• Control-Point: vor/nach Proxy, WAF, LB oder Firewall (zeigt potenzielles Intercept/Rewrite).

Für die praktische Auswertung von PCAPs ist die Dokumentation von Wireshark hilfreich, insbesondere wenn Sie Display-Filter, TLS-Metadaten oder TCP-Analysefunktionen reproduzierbar nutzen möchten.

Evidence auf Layer 7: HTTP(S), DNS, Auth und Applikationsspuren

Layer 7 entscheidet, ob Sie „nur Netzwerkstörungen“ sehen oder tatsächlich Manipulation nachweisen können. Hier finden Sie Hinweise auf Content-Rewriting, Redirect-Ketten, Header-Injection, Session-Anomalien oder unerwartete Zertifikats- und Hostname-Wechsel. Auch wenn Payloads aus Datenschutzgründen nicht vollständig geloggt werden sollen, lassen sich oft belastbare Metadaten erfassen.

• HTTP Request/Response Metadaten: method, path, status_code, user_agent, request_id/trace_id.
• Header-Anomalien: unerwartete Proxy-Header, doppelte Header, inkonsistente Host-Header.
• TLS-Indikatoren: tls_version, cipher_suite, SNI, ALPN, Zertifikatsfingerabdruck/Serial, issuer, not_after.
• DNS Evidence: Antworten mit wechselnden IPs außerhalb der Normalität, ungewöhnlich kurze TTLs, NXDOMAIN-Spikes.
• Auth-Logs: Login/Logout, MFA-Result, Token-Issuance, Session-Rotation, parallele Sessions.

Zertifikats-Anomalien als MITM-Indikator – ohne Panikmodus

Ein Zertifikatswechsel ist nicht automatisch MITM. CDNs, Rotation, Multi-Zertifikate oder Zwischenzertifikate können legitime Gründe sein. Nutzbar wird die Evidence durch Vergleich und Einordnung:

• Issuer-Änderung: neuer Aussteller oder neue Chain, die nicht zur Baseline passt.
• Serial/Thumbprint-Änderung: plötzlich andere Seriennummern ohne geplante Rotation.
• Hostname/SNI-Mismatch: Zertifikat passt nicht zur erwarteten Zielidentität.
• Validation Errors: new „untrusted“, „expired“, „name mismatch“ in Client- oder Proxy-Logs.

Wenn Sie HSTS, OCSP Stapling und TLS-Mechanismen besser einordnen möchten, ist die Übersicht von MDN Web Docs eine praxisnahe Quelle, insbesondere zur Interpretation von Browser-/TLS-Verhalten und Headern.

Korrelation: So verbinden Sie Evidence von L2 bis L7 in einer belastbaren Timeline

Der Kern eines MITM-Investigation-Playbooks ist die Korrelation: Ein Verdacht wird erst dann belastbar, wenn Sie dieselbe Kommunikation über mehrere Schichten konsistent abbilden. Dafür benötigen Sie stabile Schlüssel und ein Vorgehen, das „von außen nach innen“ oder „von unten nach oben“ funktioniert – je nach Ausgangssignal.

• Startpunkt definieren: betroffene Client-IP/MAC, betroffener User, betroffener Service oder Alarmzeitpunkt.
• L2 ↔ L3 binden: DHCP-Lease (IP↔MAC↔Zeit) plus ARP/ND-Mapping (IP↔MAC) und Switch-Port.
• L3 ↔ L4 binden: Flow/Session-Daten (src/dst IP:Port, protocol, duration, bytes/packets) plus Policy-Entscheidung.
• L4 ↔ L7 binden: request_id/trace_id, Proxy/WAF-Logs, App-Logs, TLS-Metadaten und Statuscodes.
• „Two-point Proof“: PCAP oder Telemetrie an zwei Punkten, um Manipulation/Intercept plausibel zu machen.

Entscheidungsbaum: Was gilt als starke Evidence, was nur als Hinweis?

In der Praxis brauchen Teams eine gemeinsame Erwartung, welche Artefakte als „Beweis“ gelten. Ein Entscheidungsbaum hilft, Fehlalarme zu reduzieren und Eskalationen nachvollziehbar zu machen.

• Starke Evidence: nachweisbare ARP-Poisoning-Sequenzen + MAC-Moves + simultaner Capture zeigt Traffic-Umleitung.
• Starke Evidence: Client sieht Zertifikat A, Server-seitiger Capture/Proxy-Logs zeigen Zertifikat B im selben Zeitfenster.
• Mittlere Evidence: auffällige RST-/Retransmit-Spikes + neue Transit-Flows über ein unerwartetes System.
• Schwache Evidence: einzelne RTT-Spikes, sporadische DNS-Wechsel, vereinzelte Auth-Fehler ohne Kontext.

Sofortmaßnahmen parallel zur Untersuchung: Eindämmen, ohne Evidence zu zerstören

Bei MITM-Verdacht müssen Sie häufig parallel handeln: Risiko reduzieren, aber die Untersuchung nicht „kaputt machen“. Das gelingt, wenn Maßnahmen reversibel sind und Sie vorher den aktuellen Zustand sichern (Snapshot-Prinzip).

• Quarantäne auf Access-Ebene: betroffenen Port isolieren (NAC/Port-Security), vorher MAC/ARP/Port-State sichern.
• ARP/ND-Schutz aktivieren: DAI/DHCP Snooping (falls vorbereitet), Guard-Events mitschneiden.
• Segmentierung verschärfen: temporäre ACLs zwischen betroffenen Hosts/Netzen, Logging der Matches aktiv.
• Credential Hygiene: bei Session-/Token-Verdacht betroffene Sessions invalidieren, MFA/SSO-Events besonders sichern.
• Kommunikation stabilisieren: wenn möglich Umleitung auf „Known Good“ Pfade/Proxies, um Business Impact zu senken.

Dokumentation: Artefaktliste, Mindestfelder und reproduzierbare Ergebnisse

Damit Ergebnisse später auditierbar sind, dokumentieren Sie nicht nur „was passiert ist“, sondern auch „wie Sie es festgestellt haben“. Ein gutes Playbook endet operativ mit einem strukturierten Artefaktpaket, das ein anderes Team reproduzieren kann.

• Artefakte: PCAPs (mit Capture-Punkt, Filter, Zeitbereich), Switch-Exports (MAC/ARP/STP), Firewall-Session-Logs, Proxy/WAF-Logs, DNS-Logs, Auth-Logs.
• Mindestfelder: event_time (UTC), source_system, src/dst (IP/MAC/Port), session_id/flow_id, policy_rule_id, outcome/reason.
• Timeline: zentrale Ereignisse in Reihenfolge, inklusive „known good“ Baseline-Referenzen.
• Abgrenzung: welche Hypothesen ausgeschlossen wurden (z. B. MTU/Packet Loss, legitime Zertifikatsrotation, geplante Netzwerkänderung).
• Lessons Learned: welche Logging-/Guard-Lücken die Untersuchung verlangsamt haben (für Hardening-Backlog).

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.