Wer eine IP-KVM finden will, sucht meist zuerst nach dem Gerätenamen. Der folgende Artikel zeigt, dass Angreifer genau diesen Namen oft als Erstes ändern – und dass die eigentliche Spur in den USB-Schnittstellen und der umgebenden Telemetrie liegt. Wer bösartige IP-KVM-Nutzung erkennen will, muss deshalb nicht nur nach bekannten Produkten suchen, sondern nach dem Verhalten, das ein solches Gerät am Endpoint hinterlässt. Darum geht es im Folgenden: um ip-kvm threat hunting als systematische Arbeit mit Hardware-Artefakten, nicht als Suche nach einem Etikett.
Warum IP-KVM-Angriffe außerhalb des Betriebssystems stattfinden
Ein IP-KVM verbindet Tastatur, Maus und Bildschirm über USB- und Display-Schnittstellen mit einem Netzwerkanschluss. Der Operator sitzt an einem anderen Ort und sendet Eingaben, die der Zielrechner als lokale Tastatur- und Mausbewegungen wahrnimmt. Die Sitzung läuft an der Hardware-Grenze, nicht als Prozess im Betriebssystem. Für klassische Security-Software ist das unsichtbar, weil sie im Host arbeitet. Für Threat Hunter bleibt trotzdem etwas übrig: Das Gerät muss physisch eingesteckt sein, und dabei entstehen USB-Ereignisse, Gerätebeschreibungen und Interface-Kombinationen.
Die Geräte sind nicht per se bösartig. Ein IP-KVM ist ein legitimes Werkzeug für Server- und Rechenzentrumsverwaltung, für Labore und für Administration aus der Ferne. Raritan, Avocent und ATEN sind Beispiele für enterprise-taugliche KVM-Linien, die in vielen Umgebungen normal sind. Es geht also nicht darum, KVM-Hardware zu verbieten, sondern bösartige von legitimen Einsätzen zu unterscheiden. Die Hardware-Telemetrie zeigt nicht nur, was ein Gerät zu sein behauptet, sondern auch, wie es sich am Endpoint verhält. IP-KVM-Angriffe sind dabei nur eine Spielart der Remote-Access-Angriffe.
Hardware-Telemetrie: das Namensschild und die Fußspuren
Der Gerätename ist wie ein Namensschild: Er sagt, wer da ist, und ist der schnellste Weg, eine bekannte IP-KVM zu finden. Für die USB-Geräteüberwachung sind Produkt- und Herstellername, Vendor ID und Product ID, die Gerätebeschreibung, eine eventuell vorhandene Seriennummer sowie die Interface-Klasse nützlich. Auf der Verhaltensseite stehen Verbindungs- und Trennungseignisse, die Kombination zusammengesetzter USB-Interfaces und die historische Präsenz des Geräts. Beide Seiten gehören zusammen, weil ein Name allein wenig über den Zweck einer Sitzung aussagt.
Bevor du aus einem Treffer Schlüsse ziehst, solltest du prüfen, was dein Sensor tatsächlich aufzeichnet. Unterschiedliche Endpoint-Produkte füllen diese Felder verschieden aus, und manche liefern nur einen Teil davon. SANS hat in einer Untersuchung aus dem Jahr 2026 einen endpoint-seitigen Ansatz über USB-Enumeration für PiKVM und NanoKVM gezeigt. Dort zeigte sich auch, dass sich identifizierende Zeichenketten verändern lassen. Das Namensschild ist also ein guter Anfang, aber keine Garantie. Wer nur nach Produktnamen sucht, findet die sorglosen Fälle und übersieht die vorsichtigen.
Bekannte IP-KVM-Geräte im Unternehmen identifizieren
Für den Einstieg suchst du in der USB- oder Geräte-Telemetrie nach erkennbaren Produktnamen, Herstellern und bekannten VID/PID-Kombinationen. Zu den IP-KVMs, die in veröffentlichten Angriffen eine Rolle gespielt haben, gehören PiKVM, TinyPilot, JetKVM, NanoKVM beziehungsweise Sipeed, BliKVM, GL.iNet mit GLKVM und Openterface. Such auch nach weiteren bekannten IP-KVMs, selbst wenn sie noch in keinem öffentlichen Fall aufgetaucht sind. Ein vollständiges Inventar ermöglicht später eine Verhaltensbaseline und damit die Frage, was in deiner Umgebung normal ist.
Nimm auch enterprise-KVM-Linien wie Raritan, Avocent und ATEN in die Suche auf, aber sei bei der Bewertung vorsichtig. Diese Produkte werden häufig für legitime Server- und Rechenzentrumsverwaltung eingesetzt. Ein Treffer bedeutet zunächst nur, dass die Hardware identifiziert wurde. Als Nächstes musst du prüfen, ob die Aktivität rund um dieses Gerät für einen legitimen Zweck spricht. Hier gabelt sich der Hunt: Findest du ein klares KVM, klärst du, ob es dorthin gehört. Findest du nichts Offensichtliches, gehst du zur verhaltensbasierten Jagd über.
Kontextprüfung: Wann ein KVM-Fund verdächtig wird
Ein KVM auf einem Server im Labor kann genau das sein, was du erwartest. Ein PiKVM auf einem frisch ausgegebenen Mitarbeiter-Laptop ohne Hardware-Record ist eine andere Frage. Sinnvolle Pivots sind deshalb Endpoint und Rolle, die Frage nach freigegebener oder inventarisierter Hardware, der Zeitpunkt des ersten Auftretens nahe dem Onboarding, die Seltenheit im Fleet und eine dauerhafte Verbindung ohne Neustart, Herunterfahren oder Ruhezustand. Auf der Identitätsseite kommen erwartete Anmeldegeografie, VPN- oder Proxy-Nutzung, ungewöhnliche Arbeitszeiten und andere Remote-Access-Anomalien hinzu. Diese Signale sind unterstützende Evidenz, keine Voraussetzung für den endpoint-seitigen Hunt.
Eine nützliche Heuristik lautet: Sieht das nach einem gewachsenen Homeoffice mit Dock, Monitor, Headset, Tastatur, Maus und Telefon aus, oder nach einer Maschine, deren Hauptaufgabe es ist, online zu bleiben und ferngesteuert zu werden? Eine ungewöhnlich sparsame Ausstattung mit einem dauerhaft angeschlossenen KVM-ähnlichen Gerät, wenig Peripherie-Historie und einem Anschluss nahe dem Onboarding kann ein Warnzeichen sein. Das ist ausdrücklich keine bekannte Nordkorea-Signatur, denn viele legitime Mitarbeiter haben schlichte Arbeitsplätze. Es ist eine Triage-Frage, die prüft, ob das Verhalten am Endpoint Sinn ergibt.
Die Untersuchungen von Huntress aus dem Jahr 2026 zeigen, warum Korrelation wichtig ist. PiKVM-Artefakte wurden dort zusammen mit Onboarding-Zeitpunkt, VPN- und Proxy-Infrastruktur, geografischen Zugriffsmustern, Arbeitszeiten und weiteren Identitätsdaten bewertet, nicht als Beweis für sich. In einem Fall führte diese Kombination zu der Einschätzung, die Identität des Mitarbeiters sei fragwürdig. Die Organisation bestätigte den Verdacht später, nachdem der Mitarbeiter sich weigerte, den Raum zu zeigen, und nur widerwillig vor die Kamera treten wollte. Wenn ein KVM nicht freigegeben oder nicht Standard ist, solltest du nicht raten, sondern die Legitimität aktiv bestätigen: über den Asset-Record, IT, Führungskraft oder eine physische Prüfung. Ein Hunt ist keine Anklage, sondern die Entscheidung, welche Endpoints weiter untersucht werden sollten.
Verhaltensbasierte Jagd: wenn das Namensschild fehlt
Die einfachen Indikatoren sind editierbar. Ein Gerät kann Produktnamen, Herstellerzeichenkette oder Kennungen ändern, und dann hilft nur noch der Blick auf das, was es dem Endpoint tatsächlich präsentiert. Suche nach KVM-ähnlichen Kandidaten und Human Interface Devices, also USB-Geräten, die Tastatur- oder Mausfunktionen bereitstellen. Interessant sind zusammengesetzte USB-Geräte, die zusätzlich Speicher oder virtuelle Medien, USB-Netzwerk, Video- oder Audiofunktionen oder andere ungewöhnliche Interface-Kombinationen anbieten. Wichtig ist die Seltenheit: Ein Composite Device oder Hersteller, der auf genau einem Endpoint auftaucht, verdient mehr Aufmerksamkeit als ein Modell, das in Tausenden Installationen vorkommt.
Die Regel lautet nicht HID plus Netzwerk gleich KVM. Sie lautet HID plus ungewöhnliche Zusatzfunktion gleich Kandidat, den man verstehen sollte. PiKVM dokumentiert selbst, dass es Tastatur, Maus, Massenspeicher und optional weitere Funktionen wie USB-Ethernet emulieren kann. Der Interface-Mix ist damit ein Weg, Hardware zu finden, die umbenannt wurde oder von Anfang an nicht auf deiner Liste bekannter Produkte stand. Allerdings erzeugt diese Methode auch Fehlalarme. Häufige Lookalikes sind USB-C-Docks, monitorintegrierte oder lokale KVM-Switches, Entwicklerboards, Test- und Laborgeräte sowie andere multifunktionale USB-Geräte. Diese Kandidaten musst du durch dieselben Verhaltens- und Kontext-Pivots schicken wie ein bekanntes KVM.
Ein ungewöhnliches Composite-USB-Gerät allein ist noch kein starker Kandidat. Erst die Kombination aus seltenem Gerät, KVM-ähnlichem USB-Fußabdruck, dauerhafter Präsenz, fehlendem Geschäftsgrund und einer Umgebung, die nicht ganz zusammenpasst, macht daraus einen Fall. Frage bei jedem Kandidaten, ob das Gerät zur Rolle des Nutzers passt, ob es seit dem Onboarding vorhanden war, ob der Endpoint wie ein gewöhnlicher Arbeitsplatz aussieht und ob es einen betrieblichen Grund für die Hardware gibt. So trennst du ein interessantes Artefakt von einem echten Untersuchungsfall.
Triage und dauerhafte Detektionen: vom Fund zur Regel
Eine einfache Dreiteilung hilft. Wahrscheinlich erwartbar ist ein freigegebenes KVM auf einem Server- oder Laborasset mit dokumentierter Hardware und passendem Kontext; das gehört in eine Allowlist oder ein Inventar. Bestätigen solltest du ein bekanntes KVM oder ungewöhnliches Composite Device auf einem Mitarbeiter-Endpoint ohne klaren Inventareintrag; hier validierst du mit IT, Nutzer und Asset-Record. Höhere Priorität hat KVM-ähnliche Hardware auf einem unerwarteten oder neuen Endpoint, wenn zusätzlich Persistenz, Onboarding-Zeitpunkt, ungewöhnliche Peripherie-Historie oder Identitätsanomalien hinzukommen; dann eskalierst du und bestätigst physisch. Mit USB-Telemetrie beweist du keine Attribution, aber du entscheidest, welcher Kandidat den nächsten Anruf oder Check verdient.
Auch ein trockener Hunt ist produktiv. Wenn du die nötige Sichtbarkeit validiert, bekannte Produktfamilien durchsucht, nach KVM-ähnlichen Fußabdrücken gesucht und die Lookalikes aufgelöst hast, ohne ungeklärte Hardware zu finden, ist das innerhalb der geprüften Endpoint-Abdeckung ein aussagekräftiges Ergebnis. Es ist kein perfekter Beweis, weil Hardware modifiziert werden kann und Sensoren blinde Flecken haben. Aber validierte Sichtbarkeit ohne bekannte KVM-Treffer und ohne ungeklärte Verhaltens-Fußabdrücke ist nützliche Evidenz für Abwesenheit. Und sie zeigt dir, was normal ist, was dir beim nächsten Mal hilft, das Abnormale schneller zu erkennen.
Am Ende steht eine einfache Konsequenz: Beobachtungen mit hoher Konfidenz werden zu dauerhaften Detektionen. Starte mit dem, was die Hardware über sich selbst sagt, prüfe dann, was sie dem Endpoint tatsächlich präsentiert, und nutze schließlich Hardware-, Nutzer-, Asset- und Identitätskontext, um zu entscheiden, ob die Geschichte Sinn ergibt. Schließe Docks, Entwicklerboards, freigegebene KVMs und gewachsene Homeoffice-Setups aus, bevor du eskalierst. So wird aus einem einmaligen ip-kvm threat hunting eine Regel, die auch das Gerät erwischt, das nächste Woche auftaucht. Das Namensschild hilft beim Einstieg. Der eigentliche Hunt liegt in den Fußspuren.
Quelle: nebulock.io
