MITRE ATT&CK auf Network-Telemetrie mappen: Realistische Use Cases

Das Thema MITRE ATT&CK auf Network-Telemetrie mappen klingt zunächst nach „Framework trifft Logs“ – in der Praxis entscheidet es jedoch darüber, ob Ihr SOC/NOC echte Angriffe früh erkennt oder nur Rauschen produziert. Viele Teams kennen MITRE ATT&CK als Matrix mit Taktiken und Techniken, scheitern aber beim operativen Transfer: Welche Netzwerkdaten sind wirklich geeignet? Welche Techniken lassen sich über Flow-, DNS- oder Proxy-Telemetrie realistisch erkennen – und wo sind die Grenzen, weil das Signal im Netzwerk zu schwach oder zu unspezifisch ist? Genau hier hilft ein pragmatischer Ansatz: Sie definieren pro Technik nicht „Detektion um jeden Preis“, sondern realistische Use Cases mit klaren Voraussetzungen, Telemetriequellen, erwarteten Indikatoren, häufigen False Positives und einem Verifikationsschritt. Network-Telemetrie ist besonders wertvoll, weil sie unabhängig vom Endpunkt ist (und damit auch bei EDR-Lücken hilft), weil sie an Trust Boundaries skalierbar ist und weil sie Muster über viele Systeme hinweg sichtbar macht. Dieser Artikel zeigt, wie Sie MITRE ATT&CK praxisnah auf Netzwerkdaten mappen, welche minimalen Datenquellen Sie benötigen und welche Use Cases in modernen Umgebungen (On-Prem, Cloud, Kubernetes, Remote Access) tatsächlich funktionieren.

Warum Network-Telemetrie für ATT&CK-Mappings so stark ist

MITRE ATT&CK beschreibt Angreiferverhalten. Netzwerkdaten zeigen, wie sich dieses Verhalten in Kommunikation, Namensauflösung, Verbindungsaufbau, Datenbewegung und Kontrollentscheidungen manifestiert. Besonders nützlich ist Network-Telemetrie für:

• Initial Access über externe Flächen (Edge, VPN, Web-Apps): Auffällige Muster sind häufig bereits am Gateway sichtbar.
• Discovery und Lateral Movement: Seitwärtsbewegung erzeugt oft neue Ost-West-Flows, Portscans, SMB/RPC/WinRM-Charakteristik oder ungewöhnliche Service-Zugriffe.
• Command-and-Control (C2): Beacons, DNS-Tunneling, anomale TLS-Sessions, seltene Zielhosts oder Traffic zu neu registrierten Domains.
• Exfiltration: Ungewöhnliche Datenvolumina, neue Transferpfade, seltene Protokolle oder Upload-Muster.

Als Referenz für Techniken und Taktiken ist MITRE ATT&CK die zentrale Quelle. Für viele Organisationen ist es sinnvoll, zunächst auf „Enterprise“ zu fokussieren und die Abdeckung über Netztelemetrie als eigene Sicht („Network Coverage“) zu definieren.

Grundprinzip: Technik ≠ Alert, sondern Hypothese mit Verifikationsschritt

Ein häufiges Anti-Pattern ist: „Wir bauen für jede Technik einen Alert.“ Das erzeugt entweder Alert Fatigue oder ein falsches Sicherheitsgefühl. Realistischer ist ein Mapping in drei Stufen:

• Signal: ein beobachtbares Netzwerkmerkmal (z. B. neue DNS-Domain + periodische Verbindungen).
• Hypothese: welche ATT&CK-Technik könnte dazu passen (z. B. C2 via Web Protocols).
• Verifikation: ein zweites Signal oder ein Kontextcheck (Asset-Kritikalität, Prozessdaten, Auth-Logs, Change-Korrelation).

So bleibt das Mapping operierbar: Netzwerkdaten liefern sehr gut „Anomalie + Richtung“, aber selten allein die eindeutige „Schuld“. Genau deshalb ist der Verifikationsschritt Teil des Use Cases.

Minimaler Telemetrie-Stack: Welche Netzwerkdaten Sie wirklich brauchen

Bevor Sie ATT&CK mappen, sollten Sie die Quellen konsolidieren. „Minimal“ heißt: wenige, aber wirkungsstarke Datenquellen, die an zentralen Trust Boundaries sitzen und konsistent auswertbar sind.

• Flow-Telemetrie: NetFlow/sFlow/IPFIX oder Cloud Flow Logs (5-Tuple, Bytes/Packets, Action, Interface/Zone).
• DNS-Telemetrie: Resolver-Logs (Query/Response, RCODE, Client-ID), optional Passive DNS.
• Proxy/HTTP Logs: URL/Host, Method, Status, Bytes in/out, User/Device/Identity (wo möglich).
• Firewall/Policy Logs: Allow/Deny, Rule-ID, NAT, Drop Reason (wenn verfügbar).
• TLS-Metadaten: SNI, Zertifikats-Subject/Issuer, JA3/JA4 (falls in Ihrer Umgebung zulässig und vorhanden), Handshake-Fehlerklassen.
• Remote Access Telemetrie: VPN/ZTNA Logs (User, Device, Source, Zuweisung, Session-Lifetime).

Wichtig ist die Normalisierung: Wenn „Zone“, „Asset-ID“, „Policy-ID“ und „Identity“ nicht einheitlich sind, werden Use Cases teuer und unzuverlässig.

Mapping-Methodik: Von ATT&CK zur Detektionslogik

Ein praxistauglicher Workflow besteht aus vier Schritten, die sich für jede Technik wiederholen lassen:

• Technik auswählen: Start mit Techniken, die netzseitig stark beobachtbar sind (C2, Discovery, Lateral Movement, Exfiltration).
• Beobachtbares Verhalten definieren: Welche Netzwerkhandlung muss passieren, wenn die Technik genutzt wird?
• Telemetriequelle und Felder festlegen: Welche Logs liefern das Signal? Welche Felder sind Pflicht?
• Baselines + Verifikation: Was ist „normal“? Welche zweite Quelle bestätigt den Verdacht?

Priorisierung mit einem einfachen Score

Damit Sie nicht mit „spannenden“ aber wenig wirksamen Use Cases starten, hilft ein Score aus Sichtbarkeit, Impact und Aufwand. Ein Beispiel:

$S=\frac{V\cdot I}{A+1}$

• V (Visibility): Wie gut ist die Technik über Netzwerkdaten sichtbar? (0–5)
• I (Impact): Wie hoch ist der Schaden, wenn unentdeckt? (0–5)
• A (Effort): Implementierungsaufwand inkl. False-Positive-Tuning (0–5)

Der Score zwingt zu pragmatischen Entscheidungen: Erst Use Cases mit hoher Sichtbarkeit und hohem Impact, bevor Sie in sehr endpunktlastige Techniken investieren.

Realistische Use Cases: Discovery und Reconnaissance im internen Netz

Discovery ist ein Bereich, in dem Netzwerkdaten oft überraschend stark sind, weil viele Recon-Tools typische Muster erzeugen.

Network Service Scanning (Recon über Ports und Services)

• Signal: Ein Host initiiert in kurzer Zeit Verbindungen zu vielen Zielen und/oder vielen Ports (Ost-West) mit hoher Fehlerrate (SYN ohne vollständige Sessions).
• Quellen: Flow Logs (hohe Unique-Destination-Counts), Firewall Logs (Drops), IDS/Zeek (wenn vorhanden).
• Verifikation: Asset-Rolle prüfen (Scanner-Server vs. Client), Change-Korrelation (neues Vulnerability-Scanning?), VPN-User-Kontext.
• False Positives: legitime Scanner, Monitoring-Systeme, Konfig-Drift bei Service Discovery.

Remote Services Discovery (SMB/RPC/WinRM/SSH Auffälligkeiten)

• Signal: Ungewöhnlicher Anstieg von Verbindungen auf Admin-Ports (z. B. 22/3389/445/5985/5986) von Clients, die das normalerweise nicht tun.
• Quellen: Flow Logs, Firewall Allow/Deny, Remote Access Logs.
• Verifikation: Identity (Admin?), Ticket/Change vorhanden?, betroffene Ziele in sensiblen Zonen?
• False Positives: Jump Hosts, Patch-Prozesse, neue Automatisierung.

Realistische Use Cases: Lateral Movement und Credential-bezogene Muster

Lateral Movement ist netzseitig häufig sichtbar, wenn Segmentierung vorhanden ist und wenn Sie Ost-West-Telemetrie zumindest an Boundaries sammeln.

Pass-the-Hash / SMB-basierte laterale Bewegung (indirekt)

• Signal: Viele SMB-Verbindungen (445) von einem Client zu vielen Servern, häufig kombiniert mit Auth-Fails in Identity-Logs (wenn gekoppelt).
• Quellen: Flow Logs, Windows Auth Logs (als Verifikation), Firewall Logs.
• Verifikation: ungewöhnliche Zielgruppen (Domain Controller, Fileserver), Zeitfenster korreliert mit User-Session?
• False Positives: File-Indexing, Backup-Agenten, Softwareverteilung.

RDP-Brute-Force oder Credential Stuffing gegen Remote Access

• Signal: Viele kurze Sessions zu RDP/VPN-Endpunkten, hohe Fail-Rate, auffällige Quellen (Geo/ASN), wiederkehrende Muster.
• Quellen: VPN/ZTNA Logs, Firewall Logs, Flow Logs (Session-Pattern), ggf. WAF bei Web-Login.
• Verifikation: Account-Lockouts, MFA-Prompt-Spikes, ungewöhnliche Devices.
• False Positives: Fehlkonfigurierte Clients, Passwort-Manager-Fehler, legitime Lasttests (selten).

Realistische Use Cases: Command-and-Control über DNS, HTTP und TLS

C2 ist ein Kernbereich, in dem Netzwerkdaten oft das erste verlässliche Signal liefern, weil Beacons und ungewöhnliche Zielziele auffallen, auch wenn Endpunkte fehlen.

Beaconing über HTTP(S) (periodische „Call-home“-Muster)

• Signal: Regelmäßige Verbindungen eines Hosts zu einer externen Domain/IP in konstanten Intervallen (z. B. alle 60/120 Sekunden), oft mit kleinen Payloads.
• Quellen: Proxy Logs (Requests/Bytes), Flow Logs (Periodizität), TLS-Metadaten (SNI).
• Verifikation: Domain-Reputation/Alter, Abgleich mit Asset-Funktion (Server darf raus?), DNS-Query-Historie.
• False Positives: legitime Telemetrie-Agenten, Health Checks, IoT/Monitoring.

DNS-Tunneling oder anomale DNS-Nutzung

• Signal: Sehr lange Subdomains, hohe NXDOMAIN-Raten, ungewöhnlich viele TXT-Abfragen, hohe Query-Volumen von einem Client.
• Quellen: DNS Resolver Logs, ggf. Passive DNS, Flow Logs (DNS-Volumen).
• Verifikation: Betroffene Clients (Server?), zeitliche Korrelation, Abgleich gegen bekannte legitime Patterns (CDN, Tracking, Service Discovery).
• False Positives: Content-Delivery-Mechanismen, legitime große TXT-Records (z. B. DKIM/Verifications), Fehlkonfigurationen.

Anomale TLS-Handshake-Profile (verdächtige Clients)

• Signal: Ungewöhnliche TLS-Client-Fingerprints oder Handshake-Fehlercluster zu seltenen Zielen; SNI passt nicht zu Zertifikat; seltene Issuer/Subjects in kurzer Zeit.
• Quellen: TLS-Metadaten am Proxy/LB, Flow Logs, ggf. IDS/Zeek.
• Verifikation: Prozess-/Endpoint-Daten (wenn verfügbar), Abgleich mit erlaubten Egress-Zielen, Proxy-Policy.
• False Positives: neue Browser-/Client-Versionen, legitime Embedded Clients, Fehlkonfig im Zertifikatsmanagement.

Realistische Use Cases: Exfiltration und Datenbewegung

Exfiltration über Netzwerkdaten zu erkennen ist möglich, aber erfordert Baselines und Kontext. Der Schlüssel ist: nicht nur „viel Traffic“, sondern „viel Traffic an unerwarteter Stelle“.

Exfiltration über ungewöhnliche Ziele oder Protokolle

• Signal: Ein interner Host sendet große Datenmengen zu neuen externen Zielen, die nicht in der üblichen Egress-Allowlist sind, oder nutzt seltene Protokolle/Ports.
• Quellen: Flow Logs (Bytes out), Firewall Logs (Allow/Deny), Proxy Logs (Uploads, Methoden).
• Verifikation: Datenklassifikation des Systems, Zeitfenster (außerhalb Arbeitszeit), User/Service-Identity, Change-Korrelation.
• False Positives: Backups in neue Regionen, Migrationen, neue SaaS-Integrationen.

Cloud-Exfiltration (Objektspeicher, APIs, Cross-Region Transfers)

• Signal: plötzliche Upload-Spitzen zu Storage-Endpunkten oder API-Diensten, neue Regionen, neue Accounts/Tenants.
• Quellen: Cloud Flow Logs + Cloud Audit Logs (als Verifikation), Proxy (wenn genutzt).
• Verifikation: IAM-Events (neue Keys, neue Rollen), ungewöhnliche API-Aufrufe, Datenzugriffslogs.
• False Positives: legitime Datenpipelines, ETL-Jobs, Scale-out.

Realistische Use Cases: Defense Evasion und Policy-Bypass an Trust Boundaries

Ein oft unterschätzter Bereich ist die Erkennung von Umgehungen: Angreifer (oder Fehlkonfigurationen) nutzen Pfade, die nicht vorgesehen sind. Network-Telemetrie an Trust Boundaries ist dafür ideal.

Unerwartete Ost-West-Pfade trotz Segmentierungsdesign

• Signal: Neue Verbindungen zwischen Zonen/VRFs/Namespaces, die laut Architektur nicht auftreten sollten.
• Quellen: Flow Logs an Boundary, Firewall Policy Logs (Rule-IDs), ggf. Service Mesh Telemetrie.
• Verifikation: Policy Diff (neu erlaubt?), Ticket/Change vorhanden?, betroffene Systeme kritisch?
• False Positives: neue Services, neue Dependencies, vergessenes Update von Allowlists.

Split Tunneling / Unkontrollierter Egress

• Signal: Endpoints umgehen den Unternehmensproxy/VPN und gehen direkt ins Internet, obwohl Policies „proxy-only“ erwarten.
• Quellen: Proxy Logs (fehlende Einträge), Firewall Egress Logs (direkte Ziele), VPN Logs (Session-Status).
• Verifikation: Device-Compliance, ZTNA-Policy, lokale DNS-Resolver-Nutzung.
• False Positives: Sondergeräte, Break-Glass, lokale Netze (z. B. Remote Worker ohne Always-on).

Wie Sie Use Cases „production-ready“ machen: Baselines, Tuning, Playbooks

Ein Use Case ist erst dann reif für den Betrieb, wenn drei Dinge existieren: (1) eine Baseline, (2) ein Tuning-Mechanismus gegen False Positives, (3) ein Playbook für die Reaktion.

• Baselines: normaler Egress pro Zone, normale DNS-Fehlerquoten, typische Portnutzung pro Asset-Klasse.
• Tuning: Allowlisten für Scanner/Monitoring, Service-Klassen (z. B. Backup), Zeitfenster-Regeln.
• Playbooks: Verifikation (welche Logs?), Containment (welche safe Schritte?), Evidence-Sicherung (welche Daten?).

Ein pragmatischer Qualitäts-Check pro Use Case

• Detektionsklarheit: Ist die Hypothese präzise formuliert (welches Verhalten)?
• Verifikation: Gibt es mindestens einen zweiten Check, der Fehlalarme reduziert?
• Ownership: Wer tuned? Wer reagiert? Wer entscheidet Ausnahmen?
• Messbarkeit: Können Sie False-Positive-Rate und Time-to-Detect verfolgen?

Grenzen und Erwartungen: Was Network-Telemetrie nicht gut kann

Ein realistisches ATT&CK-Mapping lebt auch von klaren Grenzen. Netzwerkdaten sind hervorragend für Kommunikation und Pfadfragen, aber schwächer bei rein lokalen Techniken.

• Schwache Sicht: lokale Privilege Escalation ohne Netzwerkaktion, rein lokale Credential-Dumps, File-Manipulation ohne Exfil.
• Verschlüsselung: TLS verschleiert Inhalte; Sie sehen Metadaten, nicht den Payload (was auch gewollt sein kann).
• Shared Services: NAT, Proxies und Gateways können Attribution erschweren, wenn Identity/Device-Mapping fehlt.
• Sampling: Flow-Sampling kann kleine, aber wichtige Signale verstecken (z. B. kurze Beacons).

Gerade deshalb ist „Network + Identity + Policy“ ein starkes Trio: Netzwerk liefert Muster, Identität liefert Attribution, Policy liefert Entscheidungsgrundlage.

Weiterführende Ressourcen für saubere Referenzen

Für die Technik- und Taktikdefinitionen ist MITRE ATT&CK die zentrale Referenz. Für praxisnahe Incident-Prozesse (inkl. Evidence, Analyse und Containment) ist NIST SP 800-61 hilfreich. Für Web- und API-bezogene Angriffsflächen, die sich gut mit Proxy/WAF-Telemetrie koppeln lassen, bietet OWASP Top 10 eine etablierte Kategorisierung. Für DNS- und TCP-Grundlagen, die bei Netzwerk-Use-Cases häufig als Begriffs- und Mechanikreferenz dienen, eignen sich RFC 1035 (DNS) und RFC 9293 (TCP).

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.