Microsoft führte mit dem Windows 10 Oktober 2018 Update den Kommandozeilen Packet Sniffer pktmon ein. In der Windows Update Version 2004 erhielt pktmon weitere Updates, welche es für die Analyse für Fragen in einem Security-Kontext interessant machen könnte.

Die Frage ist, ob analog den bekannten Tools wie tcpdump oder Wireshark nun mit pktmon auf einem Windowssystem rasche Analysen zu möglichen Indikatoren einer Kompromittierung gemacht werden können.

Die Analyse mit tcpdump unter Linux mit einigen Bash-Befehlen zur Sortierung und Filterung von Paket-Mitschnitten ist relativ mächtig und leicht zu bewerkstelligen. Daher stellt sich die Frage, ob dies mit pktmon unter Windows auch mit Boardmittel möglich ist.

Im folgenden Beitrag sollen erste Schritte mit pktmon vorgestellt werden, sowie Möglichkeiten gesucht werden rasche Analyse-Resultate aus den Mitschnitten in einem Security-Kontext zu erhalten. Dazu wurde eine kleine Lab-Umgebung mit einem aktuellen Windows 10 Pro als Test-Client sowie einem Kali-Linux als weiteren Teilnehmer am Netzwerk eingerichtet.

pktmon Grundlagen

Der Packet-Sniffer pktmon ist unter C:\Windows\System32\pktmon.exe zu finden, kann aber in der Kommandozeile mit pktmon überall ausgeführt werden.

Es empfiehlt sich ein Verzeichnis zu erstellen, in welchem die ersten Mitschnitte gespeichert werden, da unter C:\Windwos\System32\ nicht der ideale Ort dafür ist. Dafür wurde das Verzeichnis C:\tmp\pktmon erstellt.

Um eine Übersicht der Optionen von pktmon zu erhalten, kann jeweils nach jedem Kommando help angehängt werden. Weiter muss pktmon als Administrator ausgeführt werden, damit dieser effektiv genutzt werden kann.

Die meisten verfügbaren Kommandos sind selbsterklärend (filter, start, stop, etc.). Ausser allenfalls bei comp ist nicht sofort ersichtlich was sich dahinter verbirgt. Mit help kann Abhilfe geschaffen werden.

Nach dem Help-Menü kann mit pktmon comp list alle aktiven Komponenten angezeigt werden.

Nun zeigt sich, dass mit comp unteranderem die, für einen Mitschnitt verfügbaren, Netzwerkinterfaces gemeint sind. In diesem Testsystem gib es nur ein aktives Interface mit der Comp ID 1.

Da pktmon nicht explizit für Security-Fragen entwickelt worden ist, sondern für Troubleshooting, ist der gesamte Netzwerkstack mit ihren jeweiligen IDs ausgewiesen. Z.B. bei virtualisierten Umgebungen, welche mehrere Netzwerkstacks (Host, Guest, VPN, VLANs etc.) aufweisen, kann dies für die Fehlersuche hilfreich sein. Bei einem produktiven System kann die Liste der Componentes relativ lange sein, daher ist es wichtig sich bewusst zu werden, auf welchen Interfaces man den Traffic mitschneiden möchte.

Der Befehl filter erscheint auch eher für Troubleshooting relevant, wenn nur spezifische Ports, IPs, Protokolle etc. mitgeschnitten werden sollen. Für eine erste Analyse in einem Security-Kontext, ist ein kompletter Mitschnitt sinnvoll und erst für die effektive Analyse werden Sortierung und Filter benötigt.

Nun aber zu den relevanten Einstellungen für einen ersten Mitschnitt. Dazu wird der Befehl pktmon start mit entsprechenden Optionen ausgeführt. Auch hier lohnt sich der Blick in das Help-Menü.

Aus den Help-Informationen lässt sich folgender Befehl zusammensetzen, welcher einen sinnvollen Mitschnitt für eine weitere Analyse ergeben soll:

pktmon start --etw -c 1 -p 0 -k 0x010 -l multi-file

Im Folgenden die Konfiguration im Detail:

• start: Starten von pktmon
• --etw: Starten einer Logging-Session
• -c 1: Auf dem Interface mit der ID 1 soll mitgeschnitten werden
• -p 0: Das ganze Paket soll mitgeschnitten werden (per Default sind es nur 128 Bytes)
• -k 0x010: nur Raw-Paket sollten gespeichert werden, Errors und Statistiken sollen aussenvor gelassen werden
• -l multi-file: Als Default gilt die Log-Datei-Grösse 512MB und der circular-mode, welcher nach 512MB Daten die alten Einträge überschreibt. Mit multi-file, wird jeweils nach 512MB Daten eine neue Datei angelegt.

Die Dauer des Mitschnittes hängt stark von den Gegebenheiten ab. Für die ersten Versuche, welche hier vorgestellt werden, wurde jeweils nur wenige Minuten Verkehr mitgeschnitten. Mittels pktmon stop wir die Logging-Session gestoppt.

Vorbereitungen für die Analyse

Als Output erhält man eine Windows-Trace-Log-Datei im etl Format. Dies kann z.B. mittels Windows Event Viewer geöffnet werden, oder auch mit dem (nicht mehr unterstützten) Microsoft Message Analyzer. Weiter bietet pktmon die Option die etl Datei als txt zu formatieren und ab der Version in Windows Update 2004 auch in das gängige pcapng Format.

Für eine Ausführliche Analyse wäre tcpdump oder Wireshark zu bevorzugen, was mittels dem pcapng Format auch problemlos möglich ist.

Wenn aus unterschiedlichen Gründen das Laden von Tools oder der Export der Mitschnitte nicht möglich ist, bleibt einem nur der Event Viewer oder der text-basierte Export. Bei der Betrachtung der drei Dateien (.etl, .txt und .pcapng) fällt ausserdem auf, dass diese sich doch massiv in ihrer Grösse unterscheiden.

Betrachtet man die Text-Datei in einem Editor, mit dem Hintergedanken (z.B. als CSV in PowerShell) dieses rasch analysieren zu können, kann man folgendes festhalten:

• Ein Eintrag besteht aus Metadaten und dem “Raw” Packet. Wobei der Payload nicht komplett wiedergegeben wird (im pcapng-Format ist auch die Payload komplett vorhanden)
• Die Werte werden grösstenteils mit Kommas separiert
  • Meta- und Paket-Daten werden mit einem Line Break und einem Tab separiert
  • MAC SRC und MAC DST sowie IP SRC und IP DST werden jedoch mit einem > separiert
  • IP SRC und IP DST werden ausserdem noch von : angeführt und abgeschlossen

Alles in allem nicht unbedingt eine gute Ausgangslage für eine rasche Analyse auf Basis eines CSV. Der fehlende Payload in der Text-Datei kann der Analyse ausserdem viel aufschlussreichen Kontext entziehen.

Nichtsdestotrotz, die kommaseparierten Daten könnten eine Analyse mit PowerShell und dessen CmdLet Import-CSV zulassen. Wenn dies mit relativ wenig Aufwand bewerkstelligt werden kann, kann schon einiges aus den IP- und Port-Informationen gewonnen werden.

Mit PowerShell Import-CSV können Files mit Delimiter eingelesen werden, und anschliessend u.a. Filter und Sortierungen auf die entsprechenden Spalten angewandt werden.

Zu CSV “konvertieren”

Das Text-Datei-Format von pktmon ist nicht ideal, um es in eine CSV-Datei zu konvertieren, aber mit nur drei “Replacement”-Befehlen scheint eine einigermassen brauchbare Ausgabe zu entstehen.

Der folgenden PowerShell Befehl liest(Get-Content) die pktmon Text-Datei und ersetzt(-replace), die Break-Tab-Combo, um Meta- und Paket-Daten auf einer Zeile zu vereinen, : und < werden ebenfalls durch Kommas ersetzt und schlussendlich wird der Output als CSV-Datei gespeichert(Set-Content).

((((Get-Content -path .\PktMon1.txt -Raw) -replace "\r\n\t",",") -replace ":",",") -replace">",",") | Set-Content -Path .\Pktmon1.csv

Als Trade-Off sind nun die Stunden und Minuten in den Metadaten sowie die “hinteren”, variablen Teile des Pakets auch kommasepariert. Gerade der Timestamp ist für die Analyse sehr wichtig, da die zeitliche Abfolge von Aktionen sehr aufschlussreich ist (Cyberkillchain). Ein effektiver Parser für das Problem zu schreiben ist in diesem Artikel nicht das Ziel, aber wäre sicher für Analysen mit diesem Setup eine lohnende Investition.

Import-CSV nimmt standardmässig die erste Zeile der Input-Datei als Header-Informationen auf. Dies ist so nicht unbedingt von Vorteil. Weiter sind aussagekräftige Header für die weiter Analyse hilfreich. Da die Anzahl der Spalten überschaubar ist, wurde rasch von Hand Header-Informationen in die CSV-Datei eingefügt.

h, min, sec, pktnr, appear, direction, type, Interface(comp), edge, filter, orgsize, loggedsize, src.mac, dst.mac, ethertype, length, src.ip.port, dst.ip.port, a, b, c, d, e

Für die ersten Felder konnte ein aussagekräftiger Header-Name aus den Daten entnommen werden, für anschliessende Spalten, welche nicht mehr eindeutige Daten enthalten, wurde einfach mit a-e aufgefüllt.

Als nächstes wird die CSV-Datei mittels Import-CSV in eine Variable $P in PowerShell geladen, anschliessend kurze Prüfung der Daten mittels Measure-Object, um zu sehen, ob noch alle Datensätze vorhanden sind.

$P = Import-CSV -Path .\Pktmon1.csv

$P | Measure-Object

Der Counter zeigt 15068 Einträge an. Dies stimmt mit der Zahl bei der Kommandozeilen-Ausgabe (siehe Bild pktmon format & pcapng) für die pktmon Konvertierung zu .txt und .pcapng überein.

Analyse des Mitschnitts

Nun kann mittels den vielen verfügbaren PowerShell-Befehlen die Variable P abgefragt werden.

Mit welchen Services hat der Host kommuniziert?

Die Abfrage soll folgendes bewirken: Wähle die Spalten src.ip.port, dst.ip.port, direction und wähle jene Einträge aus, welche Tx (Pakete welche vom Test-Client gesendet wurden) in der Spalte Directions enthalten, dann soll das ganze sortiert nach den dst Ports sowie nur mit einzigartigen Einträgen zurückgegeben werden. Damit sollte eine erste Übersicht zu den kontaktierten Remote-Ports und -IPs erzeugt werden.

$P | select src.ip.port, dst.ip.port, direction, min | where direction -like *Tx* | sort dst.ip.port -unique

Folgendes fällt dabei Auf: Der Test-Client kommuniziert von demselben Port 63150 zu vielen unterschiedlichen Ports auf dem Host 192.168.1.29, was auf eine Port-Scan hindeutet. Der Remote-Host ist im selben Subnetz und daher wohl auch ein Client (Client-zu-Client Kommunikation), was das Szenario weiter verdächtig macht.

Der Port-Scan flutet die Betrachtung, daher könnte mit der Eliminierung des Source-Ports auf dem Test-Client ein anderes Bild gewonnen werden. Dazu wird mittels einem zusätzlichen where-Filter, der Port 63150 auf der SRC-Seite eliminiert.

Nun sieht man etwas besser, mit wem der Test-Client kommunizierte, auf Port 80 und 443 (HTTP/HTTPS) zu öffentlichen IPs, Port 53 (DNS) zum Router und Port 4444 zu einem anderen Client im selben Subnetz? Dies ist wiederum verdächtigt, Port 4444 erscheint ungewöhnlich und ist allenfalls bekannt für den Default-Port einer Metasploit Meterpreter Session. Diese Filter scheinen eine gute Möglichkeit für die Detektion von, zwar rudimentäre, aber doch aufschlussreiche Indikatoren von bösartigen Aktionen zu sein.

Wie sieht es mit DNS aus?

Bei der Betrachtung des Text-Exportes von pktmon ist aufgefallen, dass knapp die URL eines DNS Request verfügbar ist. Das kann allenfalls genutzt werden, um weitere Information aus dem Mitschnitt herauszuholen.

Dazu folgende Abfrage: Welche Pakete wurden vom Test-Client mit dem Ziel-Port 53 (DNS) verschickt, ausserdem wird die Spalte a mitangezeigt, diese enthalt die DNS-Anfragen und sind knapp noch im Log enthalten. Zusätzlich wurde der Befehl format-table angehängt. Da PowerShell ab einer gewissen Breite ein anderes Format für die Ausgabe wählt, was für die Betrachtung nicht von Vorteil ist, sorgt dieser Befehl dafür, dass der Output in einer lesbaren Tabelle daherkommt.

$P | select src.ip.port, dst.ip.port, direction, a | ? direction -like *Tx* | ? dst.ip.port -like *.53 | format-table

Die Betrachtung des Resultats kann Aufschluss geben, was auf dem Client passiert ist. Allenfalls kann man verdächtige URLs erkennen und somit Indikatoren für bösartige Aktionen feststellen.

Fazit

Mittels Windows-Boardmittel pktmon und minimalem PowerShell-Aufwand kann relativ rasch ein Mitschnitt des Datenverkehrs erstellt und analysiert werden. Man merkt, dass pktmon eher für Performance-Troubleshooting angedacht wurde. Die Analyse mittels PowerShell könnte wohl stark ausgebaut werden, ist aber für eine rasche Analyse nicht das Ziel. Trotzdem konnte mit Import-CSV und entsprechen select-, where-, und sort-Statements ein Port-Scan, verdächtige Ports und URLs identifiziert werden. Diese Indikatoren sind für sich schon wertvoll und können die Grundlage für weitere und vertiefte Analysen bilden. Für weitreichendere Analysen ist das Setup aber nicht geeignet, da z.B. ein entsprechender Parser für die Formatierung der Timestamps geschrieben werden müsste sowie die fehlende Payloads in dem Text-Export.

Pktmon biete glücklicherweise seit dem Windows 2004 Update die Exportfunktion als pcapng, was es erlaubt die Mitschnitte in Wireshark oder andren Tools zu analysieren. Somit kann immerhin ohne zusätzliche Tools Mittschnitte gemacht werden. Gerade bei Security Assessments auf produktiven Kundensystemen ist die Installation von Tools nicht immer möglich. So kann mit pktmon der Mitschnitt erzeugt werden, welcher anschliessend offline analysiert werden kann.

Über den Autor

Dominik Altermatt arbeitet seit 2003 in der IT-Branche. Unter anderem hat er sich mehrere Jahre mit Data Leakage Prevention bei einer Grossbank beschäftigt. Heute liegen seine Schwerpunkte neben klassischen Penetration Tests bei der Einführung und der Weiterentwicklung von IT-Security-Management-Prozessen. (ORCID 0000-0003-4575-4597)

Links

• https://docs.microsoft.com/en-us/windows/iot-core/manage-your-device/networkpacketcapture
• https://www.bleepingcomputer.com/news/microsoft/windows-10-quietly-got-a-built-in-network-sniffer-how-to-use/
• https://www.tcpdump.org/
• https://www.wireshark.org/