LONDON (IT BOLTWISE) – Ein Lenovo-Treiber, der digital signiert ist und bei Prüfungen zunächst keine Erkennung auslöste, lässt sich missbrauchen, um EDR- und Sicherheitsprozesse auf Kernel-Ebene zu beenden. Sicherheitsforscher zeigen, dass dabei fehlende Zugriffskontrollen und ein vereinfachter IOCTL-Handler ausgenutzt werden können. Für Unternehmen bedeutet das: Vertrauen in Signaturen allein schützt nicht mehr, sobald Angreifer ein „Legitimes“ in ihre Kette einbinden. Entscheidend wird nun eine Kombination aus Driver-Blocklisten und verhaltensbasierter Überwachung kritischer Endpunkt-Aktionen.
Angriffe, die sich „Bring Your Own Vulnerable Driver“ (BYOVD) zunutze machen, entwickeln sich von einer Randnotiz zu einem handfesten Risiko für moderne Endpoint-Detection-and-Response-Systeme (EDR). Besonders brisant ist die aktuelle Beobachtung, dass ein legitimer, digital signierter Treiber von Lenovo dazu missbraucht werden kann, Sicherheitsprozesse zu terminieren. Der Kern des Problems liegt nicht in einer „magischen“ Exploit-Technik, sondern in der Kombination aus fehlender Zugriffskontrolle im Treiber, einer klar angreifbaren Schnittstelle sowie dem Umstand, dass viele Security-Workflows primär auf Signatur- und Bekanntheitsmodelle vertrauen. Damit entsteht ein schmaler, aber gefährlicher Pfad für Angreifer.
Der Sicherheitsforscher Jehad Abudagga analysierte dabei den Treiber „BootRepair.sys“, der ursprünglich mit der Lenovo PC Manager Utility assoziiert ist. Reverse Engineering zeigt, dass der Treiber Kernel-funktionale Fähigkeiten bereitstellt, ohne die üblichen Sicherheitsbarrieren konsequent einzuziehen. Zentral ist, dass das Gerätobjekt unter einem Pfad im Windows-Kernelnamensraum angelegt wird und dabei keine restriktiven DACLs (Discretionary Access Control Lists) verwendet werden. Dadurch können auch niedrig privilegierte Nutzer mit dem Device interagieren. Ergänzend macht ein symbolischer Link das Ziel zusätzlich aus Nutzerkontexten zugreifbar, was die Hürde für eine spätere Missbrauchssequenz weiter senkt.
Technisch wird die Angriffsfläche über unzureichende Berechtigungsprüfungen bei bestimmten IRP-Operationen sichtbar. Bei einem CREATE-ähnlichen Pfad werden keine effektiven Zugriffskontrollen durchgeführt, sobald ein Handle geöffnet wurde. Damit genügt es in der Praxis, den Treiberzugriff zu erlangen, um die weitere Funktionalität des IOCTL-Handlers nutzen zu können. Der Treiber exponiert dabei einen einzigen Control-Code (0x222014), der einen 4-Byte-Input akzeptiert, der einen Prozessbezeichner (PID) transportiert. Diese PID wird dann intern an eine Routine weitergereicht, die über die Windows-Kernel-API Prozesse beendet.
Damit greift der Treiber direkt in eine Stelle ein, die für Verteidigungssysteme besonders kritisch ist: die Lebensdauer von Prozessen. Die Terminierung wird im Kernel-Kontext ausgelöst, wodurch das OS den Zielprozess effektiv stoppt, selbst wenn er als „geschützt“ oder sicherheitsrelevant eingestuft wird. Im Proof-of-Concept wurde berichtet, dass sogar Sensor-Komponenten wie der Falcon-Sensor von CrowdStrike nach dem Laden des Treibers terminierbar sind. Das illustriert, wie stark BYOVD-Angriffe die Abhängigkeit von Schutzsignalen (z. B. „Treiber ist signiert“) ausnutzen können. Ein direkter Vergleich liegt auf der Hand: Während Microsoft Defender und EDRs zunehmend auf verhaltensbasierte Telemetrie setzen, kann die Prozessabschaltung im Kernel-Schattenbereich die Reaktionsfähigkeit zeitlich überholen.
Für den Markt ist vor allem die Timing- und Trust-Problematik relevant. Wenn ein Treiber aktuell „unauffällig“ wirkt, weil er digital signiert ist und bei damaligen Scans keine eindeutigen Treffer liefert, kann er in Attack Chains als vertrauenswürdiger Baustein durchrutschen. Genau das ist die typische BYOVD-Strategie: Sicherheitsmechanismen, die primär auf Signaturvertrauen, statischen Hashes oder bekannte Malware-Indikatoren reagieren, werden umgangen. Branchenexperten betonen in diesem Zusammenhang, dass Signaturprüfung kein Ersatz für vollständige Risikoanalyse und kontinuierliche Verhaltensdetektion ist. Der Vergleich mit klassischen „malicious driver“-Angriffen zeigt den Unterschied: Hier geht es nicht um das Blockieren unbekannter Binärdateien, sondern um das Absichern des gesamten Driver-Ökosystems gegen missbrauchsfähige Schwachstellen.
Für Unternehmen ergibt sich daraus ein klarer Maßnahmenmix, der über Einzelregeln hinausgeht. Erstens sollten bekannte vulnerable Treiber gezielt blockiert werden; Microsoft stellt dafür üblicherweise einen Mechanismus zur Driver-Blockierung bereit, der in vorhandene Policies integriert werden kann. Zweitens braucht es Monitoring auf Driver-Loading-Ereignisse und Kernel-nahe Verhaltensmuster, etwa wenn sicherheitsrelevante Prozesse abrupt beendet werden. Drittens ist „least privilege“ nicht nur eine Governance-Übung: Wenn Treiberzugriffe und IOCTL-Funktionalität durchsetzen können, dass Prozesse ohne Autorisierung terminierbar sind, muss das Sicherheitskonzept bis in die Treiberfreigabe hineinreichen. Drittens sollten EDRs gezielt auf Missbrauch legitimer Treiber reagieren, nicht nur auf klassische Malware-Signaturen.
Historisch ist das Muster nicht neu, aber der Aufwand wird geringer, sobald Angreifer signierte Treiber in Reichweite der Endpunkte bringen können. In den letzten Jahren haben sich zudem Security-Modelle verschoben: von reinen File-Hash- oder Signatur-Sichtungen hin zu heuristischen Modellen für Code-Ausführung, Speicherzugriffe und Prozess-Interaktionen. Genau hier liegt der Dreh- und Angelpunkt: Ein Treiber, der „legal“ geladen wird, kann trotzdem bösartige Ziele erreichen, wenn seine Implementierung sicherheitskritische Schutzschichten auslässt. Die Branche hat gelernt, dass BYOVD kein singuläres Exploit-Szenario ist, sondern ein strukturelles Risiko des Vertrauensmodells im Betriebssystem.
Mit Blick auf die Zukunft wird entscheidend sein, wie schnell sich Driver-Compliance und Verhaltenserkennung operationalisieren lassen. Wahrscheinlich wird in vielen SOCs die Priorität auf „Treiber-Governance“ steigen: Whitelisting bzw. kontrollierte Freigaben in Verbindung mit verbesserten Telemetriedaten aus dem Kernel-Umfeld. Gleichzeitig werden EDR- und SIEM-Workflows stärker korrelieren müssen, um kurze Zeitfenster nach dem Laden eines signierten, aber missbrauchsfähigen Treibers abzusichern. Entwickler können davon profitieren, indem sie Treiber- und Agenten-Integrationen so designen, dass Sicherheitsfunktionen in unabhängigen, robusten Kontrollkanälen laufen. Unterm Strich deutet der Fall darauf hin, dass Endpoint-Schutz künftig noch konsequenter „Security by Behaviour“ statt „Security by Trust“-Zahlungen kombinieren wird.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "BYOVD-Risiko: Lenovo signierter Treiber kann EDR-Prozesse beenden" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "BYOVD-Risiko: Lenovo signierter Treiber kann EDR-Prozesse beenden" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »BYOVD-Risiko: Lenovo signierter Treiber kann EDR-Prozesse beenden« bei Google Deutschland suchen, bei Bing oder Google News!