Zum Hauptinhalt springen
S-EDV news
← Alle News
Sicherheit & Datenschutz 22.09.2026 · 9 min Lesezeit

Gefälschte LastPass-Installer: Microsoft-attestierter Treiber schaltet 145 Schutzprodukte ab

LastPass hat eine Kampagne beschrieben, die mindestens 40 Organisationen imitiert. Über eine gefälschte Authenticator-Seite auf GitHub gelangt ein von Microsoft attestierter Kernel-Treiber auf das System, der 145 Virenschutz- und Endpoint-Produkte beendet. Danach läuft der Infostealer Rapuncel. Es gibt keinen Patch, wirksam sind nur Bezugsquellen, Applikationskontrolle und entzogene Adminrechte.

Editoriale Illustration: ein Download-Pfeil mündet in einen dunklen Block, der eine Reihe von Schutzschilden zur Seite drückt KI-generiert

Wer auf Windows-Arbeitsplätzen Anwendern erlaubt, Software selbst per Suchmaschine zu finden und zu installieren, sollte diese Meldung heute lesen und nicht im nächsten Wartungsfenster. LastPass hat am 21. September 2026 gemeinsam mit Delphos Labs eine Kampagne beschrieben, die mindestens 40 Organisationen imitiert. Der Einstiegspunkt ist eine gefälschte LastPass-Authenticator-Seite auf GitHub, die per Suchmaschinenoptimierung weit oben in den Trefferlisten landete. Wer dort herunterlädt und ausführt, installiert einen Kernel-Treiber, der 145 Virenschutz- und Endpoint-Security-Produkte beendet, und anschließend den Infostealer Rapuncel.

Sofort zur Entwarnung, wo sie berechtigt ist: Es gibt keine Schwachstelle und keinen Patch. Der Angriff funktioniert nur, wenn ein Anwender eine heruntergeladene Datei selbst startet und dabei Rechte für eine Treiberinstallation erlangt. Wer Applikationskontrolle durchsetzt und keine lokalen Administratorrechte vergibt, ist strukturell nicht betroffen. Reine Linux- und macOS-Arbeitsplätze sind es ebenfalls nicht, auch wenn eine gefälschte macOS-Variante der Seite existierte. LastPass betont zudem ausdrücklich, dass keine internen LastPass-Systeme kompromittiert wurden. Es handelt sich um opportunistischen Markenmissbrauch, nicht um einen Vorfall beim Anbieter. Wer den Passwortmanager im Unternehmen einsetzt, muss deswegen weder Tresore rotieren noch das Produkt austauschen.

S-EDV hat den Vorfall bereits am 21. September in der Meldung Rapuncel: Infostealer über gefälschte GitHub-Repos eingeordnet. Dieser Artikel geht auf den inzwischen veröffentlichten Bericht selbst ein und behandelt drei Punkte, die dort noch nicht enthalten waren: was eine Microsoft-Attestierung tatsächlich bedeutet, warum die Treiber-Blockliste hier nicht hilft, und welche konkreten Spuren sich in der eigenen Umgebung suchen lassen.

Was ist passiert?

Die gefälschte Authenticator-Seite wurde am 13. August 2026 entdeckt. Sie gab sich als offizielle Produktseite aus und rankte für Suchbegriffe rund um den LastPass Authenticator weit oben. Der tatsächliche Authenticator wird über lastpass.com und die offiziellen App-Stores verteilt, nicht über eine Code-Plattform. Genau diese Erwartungslücke nutzt die Kampagne aus: Ein GitHub-Repository wirkt auf viele Anwender seriös.

Hinter dem Download-Knopf liegt keine feste Datei, sondern eine Weiterleitungskette über mehrere GitHub-Seiten und einen Server hinter Cloudflare. Der Betreiber kann das Endziel dynamisch ändern. Laut LastPass war der Server am 10. September 2026 noch aktiv und lieferte eine JavaScript-Weiterleitung aus, wobei sich der Inhalt zwischen dem 27. August und dem 10. September verändert hatte. Das ist ein gepflegter Betrieb, keine abgelegte Altlast.

Am Ende steht ein Archiv mit einem gefälschten Installer. Dieser Installer ist eine umbenannte Kopie eines echten Microsoft-Debugging-Werkzeugs. Beim Start lädt Windows eine danebenliegende Programmbibliothek aus demselben Verzeichnis, und dort steckt der Schadcode. Diese Technik heißt DLL-Sideloading. Sie ist deshalb wirksam, weil die ausführende Datei selbst echt und signiert ist und damit weniger auffällt als ein unbekanntes Programm.

Danach versucht Rapuncel, über eingebaute Windows-Funktionen System-Rechte zu erlangen, und installiert einen Kernel-Treiber als Dienst. Der Treiber gibt sich als NVIDIA-Grafikkomponente aus. Auf Kernel-Ebene arbeitet er eine fest eingebaute Liste von 145 Antiviren- und Endpoint-Security-Produkten ab und beendet sie. Erst danach beginnt der eigentliche Diebstahl.

Warum eine Microsoft-Attestierung hier nichts beweist

Der interessanteste Punkt des Berichts ist keine technische Raffinesse, sondern eine Erwartungskorrektur. Der Treiber trägt eine gültige Signatur aus Microsofts Kette für das Windows-Hardware-Kompatibilitätsprogramm. Viele Administratoren lesen eine solche Signatur als Qualitätsaussage. Sie ist aber nur der Nachweis, dass eine Datei einen Prüfprozess durchlaufen hat, nicht dass ihr Verhalten unbedenklich ist. Die Forscher formulieren es sinngemäß so: Eine Attestierung belegt, dass ein Treiber durch eine Vertrauenskette gelaufen ist, nicht dass er sicher ist.

Dazu passt die Herkunft. Es handelt sich nicht um Eigenentwicklung, sondern um eine umbenannte Komponente aus einer chinesischen Software zur Festplattenverschlüsselung, deren Ursprungstreiber im LOLDrivers-Katalog bereits als Prozess-Killer geführt wird. Die Umbenennung allein senkte die Erkennungsrate deutlich, weil verhaltensunabhängige Erkennung an Dateimerkmalen hängt.

Genau hier liegt auch die Grenze der Treiber-Blockliste. Microsofts Blockliste für angreifbare Treiber ist seit dem Windows-11-Update von 2022 standardmäßig aktiv und verhindert das Laden gelisteter Treiber. Sie arbeitet jedoch über bekannte Dateiprüfsummen. Eine umbenannte oder neu kompilierte Variante erzeugt einen neuen Prüfwert und fällt dadurch aus der Liste heraus. Die Blockliste bleibt sinnvoll und sollte aktiv sein, weil sie die große Masse bekannter missbrauchter Treiber abfängt. Als alleinige Absicherung gegen einen frisch umbenannten Treiber taugt sie nicht.

Ergänzend berichten die beteiligten Forscher, dass Microsoft das gemeldete Verhalten nicht als Sicherheitslücke im eigenen Sinne einstuft, weil der Treiber keine Microsoft-Komponente ist, und auf den gesonderten Weg für Blocklisten-Aufnahmen verwies. Das ist nachvollziehbar, verschiebt aber die Verantwortung in die Umgebung des Betreibers. Wer darauf wartet, dass ein solcher Treiber zentral blockiert wird, wartet unter Umständen lange.

Wer ist betroffen?

  • Windows-Arbeitsplätze, auf denen Anwender Software selbst suchen, herunterladen und ausführen dürfen. Das ist die Grundvoraussetzung der gesamten Kette.
  • Umgebungen ohne verwalteten Softwarekatalog, insbesondere Einzelarbeitsplätze und Homeoffice-Geräte ohne zentrale Verwaltung.
  • Geräte, deren Nutzer lokale Administratorrechte besitzen, weil die Installation eines Kernel-Treibers erhöhte Rechte voraussetzt.
  • Arbeitsplätze mit Krypto-Wallets, Entwicklerzugängen oder vielen im Browser gespeicherten Zugangsdaten, weil dort die Beute am größten ist.
  • Nicht betroffen im Sinne eines realistischen Angriffspfads sind Umgebungen mit strikter Applikationskontrolle, in denen nicht freigegebene ausführbare Dateien und Bibliotheken gar nicht erst starten.
  • Ebenfalls nicht betroffen sind Linux-Arbeitsplätze sowie Server ohne interaktive Nutzung und ohne Browser-Sitzungen, weil dort weder das Köderszenario noch die Windows-Treiberkette greift.
  • Kunden von LastPass sind nicht durch einen Vorfall beim Anbieter betroffen. Betroffen ist nur, wer den gefälschten Installer tatsächlich ausgeführt hat.

Was Rapuncel nach dem Abschalten der Schutzsoftware einsammelt, ist umfangreich: gespeicherte Passwörter aus 25 Browsern, Krypto-Dateien von 30 Wallet-Anwendungen, Discord- und Steam-Tokens, Telegram-Daten, den Windows-Anmeldeinformationsspeicher sowie Dokumente, deren Namen auf Zugangsdaten oder Wallets hindeuten. Zusätzlich werden Bildschirminhalte aller angeschlossenen Monitore und ein Systemprofil erfasst.

Wie kritisch ist das?

Technisch sauber eingeordnet ist das keine Remote Code Execution. Niemand wird aus der Ferne ohne Zutun übernommen, es gibt keine angreifbare Netzwerkkomponente und keine CVE. Der Ablauf ist: nutzergetriggerte Ausführung einer heruntergeladenen Datei, anschließende lokale Rechteausweitung, dann Abschaltung der Erkennung, dann Datenabfluss. Operativ ist das trotzdem hoch zu priorisieren, weil die Erkennung ausfällt, bevor der Schaden beginnt.

Der eigentliche Härtefall ist die fehlende Telemetrie. Wenn der Endpoint-Agent beendet wird, fehlen anschließend genau die Protokolle, mit denen man den Vorfall hätte rekonstruieren wollen. Eine Stille im Monitoring ist in diesem Szenario kein Betriebsproblem, sondern das Ereignis selbst. Hinzu kommt die Dauerhaftigkeit: Die Malware richtet sich als automatisch startender Windows-Dienst ein und beendet wieder anlaufende Schutzprogramme erneut.

Offen bleiben soll, was nicht gesichert ist. Die Einstufung von Rapuncel als verwandte Variante einer früher dokumentierten Stealer-Familie ist eine Forschereinschätzung, keine bestätigte Tatsache. Belastbare Opferzahlen liegen nicht vor, der Bericht nennt keine. Der Treiber enthält laut LastPass zusätzlich Code zum Verstecken und zum Einschleusen eines Helfers in jeden laufenden Prozess, in der beobachteten Version war diese Funktion jedoch nicht aktiv konfiguriert. Diese Unterscheidung ist wichtig: Das Potenzial ist vorhanden, die beobachtete Nutzung war enger.

Was sollten Admins jetzt tun?

  • Zuerst inventarisieren statt patchen: Feststellen, auf welchen Arbeitsplätzen Anwender überhaupt selbst Software installieren dürfen und wer lokale Administratorrechte besitzt. Diese Liste ist die eigentliche Risikoliste.
  • Verbindliche Bezugsquellen für Software festlegen und technisch durchsetzen: Herstellerseite oder interner Katalog, keine Suchmaschinentreffer, keine Code-Plattform-Repositorys ohne geprüfte Herkunft. Eine Richtlinie ohne technische Durchsetzung ändert hier nichts.
  • Applikationskontrolle einführen oder ausweiten, etwa App Control for Business beziehungsweise die Vorgängermechanismen. Das verhindert nicht nur den Start unbekannter Programme, sondern bremst auch DLL-Sideloading über umbenannte legitime Dateien.
  • Microsofts Blockliste für angreifbare Treiber aktiv halten und ihre Grenze kennen: Sie greift über bekannte Prüfsummen und erfasst umbenannte Varianten nicht.
  • Treiber-Signatur- und Ladeereignisse auswerten. Neu registrierte Kernel-Treiber-Dienste auf Arbeitsplatzsystemen sind selten und sollten begründbar sein.
  • Manipulationsschutz der Endpoint-Lösung aktivieren, sofern vorhanden, und prüfen, ob er auch gegen Beendigung aus dem Kernel-Kontext heraus wirkt. Viele Schutzmechanismen setzen auf Rechteprüfungen, die auf dieser Ebene nicht mehr greifen.
  • Das unerwartete Stoppen von Sicherheitsdiensten oder ein Abriss der Telemetrie als Alarm verarbeiten, nicht als Rauschen. Dieser Alarm muss eine Person erreichen.
  • Proxy-, DNS- und Firewall-Protokolle der letzten Wochen auf Downloads sehr großer Archive aus unbekannten Quellen und auf Weiterleitungsketten von Code-Plattformen zu fremden Hosts prüfen.
  • Anwender konkret befragen, ob in den letzten Wochen Software über Suchmaschinentreffer bezogen wurde. Das liefert schneller eine Verdachtsliste als jede Forensik.
  • Speicherung von Passwörtern im Browser unterbinden und auf einen verwalteten Passwortmanager umstellen. Der Browser-Tresor ist bei dieser Malware das erste Ziel.
  • Bei Verdacht Zugangsdaten und Sitzungen von einem sauberen Gerät aus rotieren: Browser-Passwörter, gespeicherte Anmeldeinformationen, Token, Entwicklerzugänge. Gestohlene Sitzungsdaten umgehen die Zwei-Faktor-Anmeldung.
  • Bei bestätigtem Befall neu aufsetzen statt bereinigen. Auf einem System, auf dem fremder Kernel-Code lief, ist Bereinigung eine Vertrauensfrage ohne belastbare Antwort. Vorher Sicherung und Wiederherstellbarkeit der Nutzerdaten prüfen.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist das weniger ein Malware-Thema als eine Frage der Beschaffung. Solange ein Mitarbeiter ein Authenticator-Werkzeug oder einen Passwortmanager selbst über eine Suchmaschine findet und installiert, entscheidet die Trefferliste darüber, welche Software im Unternehmen läuft. Angreifer investieren genau dort, weil es funktioniert und weil Suchmaschinenoptimierung deutlich billiger ist als eine Schwachstelle.

Der zweite Punkt betrifft die Erwartung an Erkennungstechnik. Eine Architektur, die vollständig auf Erkennung aufbaut, hat in diesem Szenario nichts mehr, sobald der Treiber geladen ist. Maßnahmen, die vorher wirken, sind unabhängig davon, ob ein bestimmter Treiber bereits auf einer Liste steht: kein lokaler Administrator, keine freie Softwareinstallation, kein Start nicht freigegebener Dateien. Das ist unbequemer als ein Produktkauf, aber es ist die einzige Ebene, die hier greift.

Drittens der nüchterne Blick auf die Folgekosten. Der Aufwand liegt nicht im Neuaufsetzen eines Notebooks, sondern im Rotieren aller Zugänge, die auf diesem Gerät benutzt wurden, und im Prüfen der Dienste, in denen diese Zugänge gültig waren. Ein aktuelles Verzeichnis darüber, welcher Arbeitsplatz welche Dienste nutzt, verkürzt diese Arbeit erheblich. Wer dieses Verzeichnis nicht hat, merkt es genau in dem Moment, in dem er es braucht.

Passende Anleitungen auf S-EDV

Quellen

InfostealerKernel-TreiberEDRWindowsApplikationskontrolleGitHubZugangsdatenBYOVD