NETZWERK & SICHERHEIT
Wer spricht da eigentlich? Netzwerkkommunikation unter Windows sichtbar machen
📖 Lesezeit: ca. 13 Minuten · Juli 2026 · ISW Network Communication Monitor 2.0
Auf einem durchschnittlichen Windows-Rechner bestehen zu jedem Zeitpunkt zwischen 50 und 300 Netzwerkverbindungen. Ein netstat -ano zeigt davon Adressen, Ports und Prozess-IDs – und lässt Sie mit den eigentlichen Fragen allein:
Welches Programm gehört zu PID 8824? Ist es signiert? Wohin geht die Verbindung – und zu wem gehört diese IP? Ist das normal für diesen Rechner? Und wenn nicht: Was mache ich jetzt damit?
Genau dafür habe ich den ISW Network Communication Monitor gebaut. Er beantwortet diese Fragen in einer Oberfläche – ohne Agent, ohne Cloud, ohne zusätzlichen Treiber. Und in Version 2.0 geht er zwei entscheidende Schritte weiter: Er erkennt, was anders ist als sonst – und er fragt nicht nur, welches Programm spricht, sondern in wessen Auftrag.
Was das Werkzeug macht
Der Monitor liest fortlaufend alle aktiven TCP- und UDP-Verbindungen sowie alle lauschenden Ports aus und reichert jede Zeile mit dem an, was zur Beurteilung nötig ist:
| Prozesszuordnung | Name, PID und vollständiger Pfad des verursachenden Programms |
| Prozessherkunft | Kommandozeile, Elternprozess und Abstammungskette – neu in 2.0 |
| Dienstauflösung | Welcher Dienst steckt hinter svchost.exe? – neu in 2.0 |
| Signaturprüfung | Ist die Datei digital signiert – und von wem? |
| Einordnung des Ziels | Loopback, privates Netz oder Internet – farblich unterschieden |
| Namensauflösung | Rückwärtsauflösung und – neu in 2.0 – der TLS-Servername aus dem Handshake |
| Herkunft | Land und Netzbetreiber öffentlicher Ziele (optional, per Opt-in) |
| Messwerte | Latenz sowie Datenrate je einzelner Verbindung |
| Risikobewertung | Regelbasierte Einstufung mit Begründung und Handlungsempfehlung |
Aus PID 8824 wird damit: MsSense, signiert von Microsoft, spricht nach Irland zu einem Microsoft-Rechenzentrum, TLS-Name mdav.eu.endpoint.security.microsoft.com, 50 ms Latenz – also der Defender-Cloudschutz. Diese Einordnung dauert eine Sekunde statt zehn Minuten Recherche.
Für wen ist das gedacht?
🔧 Administratoren und Dienstleister
Ein Rechner verhält sich auffällig, ein Server soll auf seine Erreichbarkeit geprüft werden, eine Software kommuniziert mehr, als sie soll. Der Monitor beantwortet das ohne Agenteninstallation – auch über WinRM auf entfernten Systemen.
🛡️ Sicherheits- und Compliance-Verantwortliche
NIS2 und BSI IT-Grundschutz verlangen, dass Sie Ihre Kommunikationsbeziehungen kennen und Vorfälle nachvollziehen können. Der Monitor liefert Berichte samt Erfassungsnachweis – und dokumentiert jeden Eingriff.
🚨 Erstmaßnahmen bei einem Verdachtsfall
Wenn ein System kompromittiert sein könnte, zählen die flüchtigen Daten: aktive Verbindungen, offene Ports, angefragte Namen, laufende Kommandozeilen. Genau die sind nach einem Neustart weg – und bei einer späteren Datenträgersicherung nicht mehr zu rekonstruieren.
Die Arbeitsbereiche im Überblick
Die Oberfläche gliedert sich in elf Registerkarten, die man sich als vier Gruppen merken kann:
1. Lagebild – Dashboard mit Kennzahlen, Durchsatzverlauf, den aktivsten Prozessen und Gegenstellen sowie Aufschlüsselungen nach Zustand, Protokoll, Port und Zielland.
2. Detailanalyse – Verbindungen (alles, filterbar und sortierbar), Sicherheitsanalyse (nur die auffälligen Fälle mit Begründung), Lauschende Ports (Ihre Angriffsfläche, exponierte Dienste gesondert markiert) und das Kommunikationsdiagramm als visuelle Landkarte.
3. DNS – konfigurierte Server, mitgelesenes DNS-Protokoll des Clients und eine DNS-Sicherheitsanalyse, die auffällige Muster erkennt: ungewöhnlich lange Namen, hohe Fehlerraten, verdächtige Endungen, Tunnelverdacht.
4. Zeitachse und Ausgabe – Verlauf mit Zeitpunktabfrage („Was lief gestern um 14:00?”), Verkehr mit Datenvolumen je Zeitraum und Gegenstelle sowie der Mustersuche, dazu Reports für HTML, PDF und CSV.
Der Verlauf ist der Unterschied zu netstat. Alle Beobachtungen wandern in eine lokale SQLite-Datenbank – inklusive Kommandozeile und Elternprozess. Damit lässt sich rückwirkend beantworten, was zu einem bestimmten Zeitpunkt aktiv war, ob eine Verbindung neu ist oder seit Wochen besteht, und mit welchem Aufruf ein Prozess gestartet wurde, der längst beendet ist.
Wenn das Werkzeug des Angreifers signiert ist
Jahrelang war die Faustregel einfach: unsigniert ist verdächtig, signiert ist in Ordnung. Diese Regel trägt nicht mehr. Der Standardweg heutiger Angriffe führt über Programme, die Windows selbst mitbringt und die Microsoft selbst signiert hat:
curl.exe · msiexec.exe · regsvr32.exe · bitsadmin.exe
Sie liegen in System32, sie sind gültig signiert, sie sind auf jedem Rechner vorhanden. Eine Prüfung, die nur auf die Signatur schaut, stuft sie zwangsläufig als unauffällig ein – und übersieht damit genau die Kategorie, die in der Praxis am häufigsten vorkommt.
Version 2.0 bewertet deshalb nicht mehr nur die Datei, sondern ihren Auftrag. Zu jeder Verbindung ins Internet ermittelt der Monitor zusätzlich die vollständige Kommandozeile, den erzeugenden Elternprozess und die Abstammungskette. Aus einer harmlosen Zeile wird damit ein vollständiger Befund:
vorher: powershell.exe (PID 8824) → 185.243.x.x:443 [signiert ✓]
jetzt: powershell.exe (PID 8824) → 185.243.x.x:443
Abstammung: winword.exe → cmd.exe → powershell.exe
Kommandozeile: powershell -nop -w hidden -enc SQBFAFgA…
Dieselbe Verbindung, dieselbe gültige Signatur – aber eine völlig andere Bewertung. Der Monitor erkennt drei Fälle:
| Auffällige Kommandozeile | Merkmale wie -enc, -w hidden, -bypass, downloadstring oder eine URL im Aufruf – Stufe „Hoch” |
| Untypischer Elternprozess | Eine Shell, gestartet aus Word, Excel, Outlook oder Acrobat – die klassische Makro-Kette. Stufe „Hoch” |
| Systemprogramm im Netz | Ein bekanntes Bordmittel spricht nach außen, ohne auffälligen Aufruf – als Hinweis vermerkt, nicht als Befund |
Ein Nebeneffekt derselben Erweiterung: svchost.exe wird endlich lesbar. Die häufigste und nichtssagendste Zeile jeder Netzwerkliste zeigt jetzt den Dienst dahinter – svchost · WpnService statt svchost (9008). Und wenn Pfad und Dienstliste einmal nicht zusammenpassen, ist das für sich schon ein Befund.
Das gilt auch remote. Über WinRM werden Kommandozeile, Elternprozess und Dienstzuordnung genauso ermittelt wie lokal – ohne auf dem Zielsystem etwas zu installieren. Wer 400 Kundensysteme betreut, prüft damit die gesamte Domäne auf dieselbe Frage.
Abweichungen statt Momentaufnahmen
Eine Momentaufnahme sagt Ihnen, was gerade läuft. Sie sagt Ihnen nicht, ob das ungewöhnlich ist. Ein Dienst, der seit drei Wochen jede Nacht um 3:14 Uhr eine Verbindung zu einem Hoster in Übersee aufbaut, fällt niemandem auf – man müsste zufällig um 3:14 Uhr hinschauen.
Version 2.0 wertet deshalb den aufgezeichneten Verlauf aus und meldet Abweichungen vom Üblichen:
| Neue Gegenstelle | Ein öffentliches Ziel, das in den letzten Wochen nie vorkam |
| Neuer lauschender Port | Die Angriffsfläche hat sich verändert |
| Neuer Prozess im Netz | Ein Programm spricht erstmals nach außen |
| Außerhalb der Betriebszeit | Der Buchhaltungs-PC um drei Uhr nachts |
| Datenmenge und -richtung | Erkennt auch langsamen Abfluss. Arbeitsplätze empfangen normalerweise überwiegend – das Gegenteil ist erklärungsbedürftig |
| Beaconing-Verdacht | Verbindungen in auffällig gleichmäßigen Abständen – typisch für automatisierte Rückmeldungen an einen Steuerserver |
| Schatten-IT | Freigabeliste erlaubter Dienste: Alarm, wenn jemand Dropbox nutzt, obwohl nur OneDrive freigegeben ist |
Zugestellt wird per E-Mail, wahlweise zusätzlich über das Windows-Ereignisprotokoll mit festen Kennungen – daraus erzeugt ein RMM unmittelbar ein Ticket – oder über einen Webhook an Teams oder ein Ticketsystem. Bei Befunden zur Prozessherkunft führt die Meldung Abstammung und Kommandozeile gleich mit: Die Rufbereitschaft kann nachts entscheiden, ohne sich erst auf den Rechner zu verbinden.
Gegen Alarmmüdigkeit: Befunde werden gebündelt statt einzeln verschickt, Ruhezeiten lassen nur die Stufe „Hoch” durch, hohe Schweregrade können an einen eigenen Empfänger gehen. Und verlaufsbasierte Alarme feuern erst nach einer Einlernphase – sonst wäre in den ersten Tagen schlicht alles „neu” und damit wertlos.
Beaconing – und die Ehrlichkeit über die eigene Messgrenze
Beaconing ist das regelmäßige Nachhausetelefonieren einer Schadsoftware: alle fünf Minuten eine kurze Anfrage, ob es neue Befehle gibt. Der Verkehr sieht harmlos aus – HTTPS, wenig Volumen, oft zu einer Cloud-Adresse. Verräterisch ist nicht der Inhalt, sondern der Rhythmus. Menschliche Nutzung schwankt stark, ein Automat hält seinen Takt.
Im Tab Verkehr lässt sich der aufgezeichnete Verlauf danach durchsuchen. Die Tabelle zeigt je Gegenstelle die beteiligten Prozesse, den mittleren Abstand und die Streuung der Abstände.
Und hier wird es interessant: Die Zeitstempel stammen aus dem Messtakt des Monitors, sind also darauf gerastert. Dadurch wirkt jede Folge gleichmäßiger, als sie tatsächlich ist – im Extremfall misst man nur den eigenen Takt. Der Monitor weist deshalb je Treffer die erreichbare Messauflösung aus und verwirft Muster, deren Abstand nicht deutlich über dem Messintervall liegt. Liegt die gemessene Streuung unterhalb dieser Grenze, steht das ausdrücklich dabei: nicht bestimmbar.
Das ist unbequemer als eine grüne Zahl – aber es ist der Unterschied zwischen einem Messwert und einer Behauptung. Und es hat einen praktischen Nutzen: Wer die Mustersuche ernsthaft einsetzt, weiß damit, dass er das Messintervall klein halten muss.
Ebenso ehrlich: Die ersten Treffer sind fast immer legitim. Schutzsoftware, Fernwartung, Update- und Backup-Dienste melden sich naturgemäß in festen Abständen. Der Wert entsteht über die Zeit – wer die erklärten Gegenstellen einmal in die Ignorierliste aufnimmt, für den ist danach jeder neue Treffer erklärungsbedürftig.
TLS-Namen sichtbar machen, wo DNS schweigt
Immer mehr Kommunikation entzieht sich der DNS-Beobachtung: verschlüsseltes DNS (DoH/DoT), fest hinterlegte IP-Adressen, Antworten aus dem Cache. Übrig bleibt eine nackte IP.
Bei jedem TLS-Handshake überträgt der Client jedoch den angefragten Servernamen im Klartext – die Server Name Indication. Version 2.0 liest diesen Namen über eine ETW-Sitzung mit. Aus einer nichtssagenden Adresse wird:
Es wird nichts mitgeschnitten und nichts entschlüsselt – nur der ohnehin unverschlüsselte Namensteil ausgewertet. Und wo die Zuordnung nicht eindeutig ist, kennzeichnet das Werkzeug sie als Vermutung, statt zu raten.
Vom Befund zur Maßnahme
Erkennen ist die eine Hälfte. Version 2.0 bietet vier Reaktionen direkt aus der Verbindungsliste heraus:
▶ Verbindung trennen – beendet eine einzelne TCP-Verbindung sofort.
▶ Prozess beenden – nach Rückfrage, mit Anzeige des betroffenen Programms.
▶ Paket-Mitschnitt – schneidet gezielt den Verkehr dieser Gegenstelle mit (Windows-Bordmittel pktmon), konvertiert nach pcapng und übergibt an Wireshark. Ohne zusätzlichen Sniffer beim Kunden.
▶ Per Firewall blockieren – zeigt zunächst, ob bereits Regeln auf dieses Ziel passen, und legt dann eine dauerhafte Blockregel an: IP, Programm oder beides.
Mit Sicherheitsnetz: Liegt das Blockierungsziel nicht im Internet, folgt eine zweite, ausdrückliche Warnung. Eine Blockade interner Adressen kann den Domänencontroller, DNS, das Standardgateway oder die eigene Fernwartung aussperren. Diese Rückfrage kam nach dem ersten Testtag dazu – ich hätte mir beinahe das Testnetz zerlegt.
Und was ist mit Process Explorer und Sysmon?
Diese Frage kommt zuverlässig – zu Recht. Die Sysinternals-Werkzeuge sind hervorragend, kostenlos und in jeder Umgebung ohne Beschaffung einsetzbar. Seit Februar 2026 ist Sysmon sogar ein integriertes Windows-Feature und wird über Windows Update gepflegt. Wer damit arbeitet, macht nichts falsch.
Der Unterschied liegt nicht in der Datenerfassung, sondern in dem, was danach passiert:
| Werkzeug | Was es leistet – und wo es endet |
|---|---|
| TCPView | Verbindungen mit Prozesszuordnung, live. Keine Signaturprüfung, keine Ziel-Einordnung, kein Land, kein TLS-Name, keine Historie, keine Berichte. |
| Process Explorer | Prozesszentriert und stark bei Signatur, Handles und Modulen – mit VirusTotal-Anbindung, die wir nicht haben. Verbindungen sind dort ein Reiter je Prozess; „welche Ziele kontaktiert dieses System insgesamt” beantwortet es nicht. |
| Sysmon | Protokolliert ereignisgesteuert und damit lückenloser als unser Intervall-Ansatz. Aber: keine Oberfläche, keine Bewertung, keine Reaktion. Erst XML-Konfiguration plus SIEM und Regelpflege machen daraus eine Aussage. |
Genau dazwischen setzt der Monitor an. Er liefert keine Rohdaten, sondern die fertige Einordnung – Signatur, Zielkategorie, Land, TLS-Name, Kommandozeile, Abstammung, Bewertung mit Begründung. Er vergleicht gegen die eigene Historie, statt starre Schwellen zu prüfen. Er erlaubt die Reaktion aus derselben Liste heraus. Und er erzeugt am Ende ein Dokument, das man einem Kunden oder Prüfer vorlegen kann.
Kurz gefasst: TCPView zeigt Ihnen die Verbindung. Sysmon protokolliert sie. Der Monitor sagt Ihnen, ob sie normal ist – auf vielen Systemen gleichzeitig, mit Verlauf, ohne Rollout und mit einem Nachweis am Ende. Das ist kein Ersatz für Sysinternals, sondern eine andere Arbeitsebene: nicht Diagnose am Einzelsystem, sondern der Arbeitsablauf eines Dienstleisters.
Ein praktischer Punkt am Rande: Das integrierte Sysmon gibt es für Windows 11 und Server 2025 – nicht für Windows 10 oder Server 2016 bis 2022, die bei vielen Kunden noch den Bestand ausmachen. Der agentlose Weg über WinRM funktioniert dort weiterhin.
Für den Flottenbetrieb: die Kommandozeile
Wer viele Systeme betreut, klickt nicht. Zum Paket gehört daher nccmon.exe – dieselben Dienste wie die Oberfläche, nur ohne Fenster:
nccmon report –format pdf –out D:\Berichte –case TICKET-1234
nccmon history –at “2026-07-17 14:00” –filter chrome
nccmon listeners –exposed –host SRV-WEB01
nccmon beacons –hours 48 –jitter 10
nccmon audit –verify
Entscheidend ist der Rückgabewert: 0 unauffällig, 1 beobachten, 2 Handlungsbedarf. Damit erzeugt ein RMM ein Ticket, ohne die Ausgabe auswerten zu müssen. Ein Angriffsflächen-Audit über die gesamte Domäne ist damit ein Einzeiler in einer Schleife.
Nachweise, die einer Prüfung standhalten
Ein Werkzeug, das flüchtige Daten erfasst und ins System eingreift, muss belegen können, was es wann gesehen und was es verändert hat. Version 2.0 tut das automatisch:
✔ Zeitbasis
Jeder Bericht führt einen Erfassungsnachweis: Zeitpunkt lokal und in UTC, Zeitzone, konfigurierte Zeitquelle, Werkzeugversion, Erfassungsart und Messintervall.
✔ Integrität
Jede erzeugte Datei wird mit SHA-256 versiegelt; die Prüfsumme liegt als Begleitdatei daneben und lässt sich mit Bordmitteln gegenprüfen.
✔ Nachvollziehbarkeit
Jeder Eingriff landet in einem nur anhängenden Protokoll mit Hash-Kette. Eine nachträgliche Änderung bricht die Kette und wird bei der Prüfung erkannt.
✔ Benannte Grenzen
Der Bericht sagt ausdrücklich, dass in Intervallen gemessen wird und kurzlebige Verbindungen zwischen zwei Messpunkten fehlen können.
Liegen auffällige Verbindungen vor, führt der Bericht einen eigenen Abschnitt Prozessherkunft auffälliger Verbindungen mit Prozess, Elternprozess und vollständiger Kommandozeile. Die CSV-Ausgabe führt dieselben Angaben als eigene Spalten – damit lässt sich in Excel filtern oder eine ganze Flotte auf denselben Aufruf abgleichen.
Ich nenne das Ergebnis bewusst nicht „Forensik”. Es gibt kein Speicherabbild und keine Datenträgersicherung. Was es ist: Live-Response – die Sicherung genau der flüchtigen Daten, die später unwiederbringlich verloren wären. Eine belastbare Vorarbeit für einen Forensiker, kein Ersatz für ihn. Wer diese Unterscheidung verwischt, riskiert in einem Verfahren mehr als ein Werkzeug.
Technischer Rahmen
| Plattform | Windows 10/11 und Windows Server, eigenständige Anwendung ohne Agent |
| Rechte | Läuft auch ohne Administratorrechte; für Prozesspfade, Kommandozeile und Elternprozess, Durchsatz je Verbindung, TLS-Namen und Eingriffe werden sie benötigt |
| Remote | Überwachung entfernter Systeme über WinRM, ohne dort etwas zu installieren – inklusive Prozessherkunft und Dienstauflösung |
| Datenhaltung | Lokal: SQLite-Verlauf und INI-Konfiguration im Benutzerprofil, Kennwörter AES-256-verschlüsselt |
| Externe Abfragen | Nur die optionale GeoIP-Auflösung, standardmäßig deaktiviert. Sonst verlässt kein Datum das System |
Fazit
Netzwerküberwachung scheitert selten am Sammeln von Daten, sondern an deren Einordnung. Der ISW Network Communication Monitor beantwortet die Fragen, die im Ernstfall zählen: Wer spricht mit wem? In wessen Auftrag? Ist das normal? Was tue ich dagegen? Und die vierte, die im Nachgang oft die wichtigste ist: Kann ich es belegen?
ISW Network Communication Monitor 2.0
Live-Monitoring, Prozessherkunft, Sicherheitsanalyse, DNS-Überwachung, Alarmierung und forensische Nachweise für Windows – inklusive Kommandozeile für den Flottenbetrieb.
Jörn Walter · IT-Service Walter ·
der-windows-papst.de |
isw-adtools.de