Lost-Device-Pentest: Was ein verlorener Laptop wirklich preisgibt

Ein Notebook bleibt im ICE liegen, wird aus dem Auto gestohlen oder verschwindet am Flughafen. Dann heißt es meist, die Platte sei ja verschlüsselt. Ob das reicht, hängt davon ab, ob der Finder auch die Zugangsdaten hat, etwa eine im Zug beobachtete PIN, und falls nicht, ob die Verschlüsselung einem Angreifer mit Zeit und Werkzeug standhält.

Das prüfen wir in einem Lost-Device-Pentest. Wir bekommen ein Gerät aus dem Standard-Rollout und spielen zwei Szenarien durch. Im ersten hat der Angreifer Gerät und Zugangsdaten und damit eine gültige Identität. Im zweiten hat er nur die Hardware, ausgeschaltet oder im Sperrbildschirm. In beiden Fällen versuchen wir, an Daten, weitere Zugangsdaten oder einen Zugang ins Unternehmensnetz zu kommen.

Szenario 1: verlorenes Gerät mit Zugangsdaten

Dass ein Angreifer Gerät und Anmeldedaten hat, ist kein Sonderfall. Mal wurde die Windows-PIN im Zug über die Schulter beobachtet, mal liegt das Passwort auf einem Zettel in der Laptoptasche oder das Notebook ging entsperrt verloren. Und manchmal gibt ein ausgeschiedener Mitarbeiter sein Gerät einfach nie zurück. BitLocker, Secure Boot und DMA-Schutz spielen dann keine Rolle, der Angreifer meldet sich ganz normal an.

Und diese Anmeldung ist viel wert. Bei Windows Hello for Business gilt der gerätegebundene Schlüssel zusammen mit der PIN als Zwei-Faktor-Authentifizierung, die auch die MFA-Anforderungen von Entra ID erfüllt. Laptop plus PIN ergibt also eine vollständige Identität mit MFA. Ein Durchprobieren der PIN verhindert das TPM zwar durch Anti-Hammering, aber eine beobachtete PIN muss niemand raten. Token Protection hilft ebenfalls nicht, weil sie nur die Nutzung gestohlener Tokens auf anderen Geräten verhindert, und der Angreifer sitzt ja am Originalgerät.

Was eine gültige Identität öffnet

In der Cloud meldet Single Sign-on über den Primary Refresh Token den Angreifer in der Regel ohne weitere Abfrage bei Outlook, Teams, SharePoint und OneDrive an, und für Conditional Access ist es ein registriertes, konformes Gerät. Von dort aus lassen sich Daten abziehen, Kollegen aus einem vertrauenswürdigen Postfach heraus phishen und Hintertüren einrichten, etwa Weiterleitungsregeln im Postfach oder, je nach Einwilligungsrichtlinie des Tenants, Zustimmungen für OAuth-Apps. Solche App-Zustimmungen überleben ein Zurücksetzen des Passworts und müssen gezielt entfernt werden.

Lokal liegen im Benutzerkontext gespeicherte Browser-Passwörter, Einträge im Credential Manager und Zugänge zu internen Anwendungen. Gelingt die Rechteausweitung zum lokalen Administrator, entscheidet die Härtung über den weiteren Verlauf. Credential Guard schützt NTLM-Hashes und Kerberos-Tickets von Domänenkonten und ist ab Windows 11 22H2 auf geeigneten Enterprise-Geräten standardmäßig aktiv. Lokale Konten in der SAM schützt es dagegen nicht. Ohne Windows LAPS teilen sich oft alle Geräte dasselbe lokale Admin-Passwort, und ein einziges Notebook öffnet die ganze Flotte.

Im Netzwerk verbindet sich das VPN in vielen Umgebungen selbstständig. Ab hier ist das Szenario ein klassischer Assumed-Breach-Pentest aus Sicht eines normalen Domänenbenutzers. Typische Wege führen über AD-Enumeration, Kerberoasting, fehlerhafte ACLs oder Schwachstellen in AD CS bis zu privilegierten Konten.

Der Wettlauf mit der Sperrung

In diesem Szenario zählt vor allem Zeit. Für die Notfall-Sperrung eines Benutzers deaktiviert man das Konto, widerruft Sitzungen und Refresh Tokens und deaktiviert die registrierten Geräte. Selbst danach bleiben bereits ausgestellte Access Tokens standardmäßig etwa eine Stunde gültig, sofern die Anwendung kein Continuous Access Evaluation (CAE) unterstützt, und Sitzungs-Cookies einzelner Anwendungen laufen nach deren eigenen Regeln aus. Die lokale Windows-Anmeldung funktioniert über zwischengespeicherte Anmeldedaten weiter, bis das Gerät von der Sperrung erfährt.

Ein Remote Wipe über Intune greift nur, wenn das Gerät online ist. Bleibt es offline, sind die lokalen Daten weiter erreichbar. Im Pentest messen wir deshalb auch, wie lange die Identität nach der Verlustmeldung tatsächlich noch funktioniert.

Szenario 2: physischer Zugriff ohne Zugangsdaten

Im zweiten Szenario hat der Angreifer nur die Hardware, ohne Netzwerkzugang und ohne Benutzerkonto. Damit fallen viele Schutzmaßnahmen weg, die im Büro selbstverständlich wirken. Er kann das Gerät beliebig oft neu starten, von externen Medien booten, das Gehäuse öffnen und sich Wochen Zeit lassen. Anders als bei einem klassischen Infrastruktur-Pentest arbeiten wir hier deshalb auch auf Firmware- und Hardware-Ebene.

In der Praxis unterscheiden wir zwei Zustände. Ein ausgeschaltetes Gerät ist der günstigste Fall für den Verteidiger, weil die Schlüssel nicht im Speicher liegen. Ein Gerät im Sleep-Modus mit Sperrbildschirm ist deutlich interessanter. Der Datenträger ist bereits entsperrt, der Schlüssel liegt im RAM, und jede Schnittstelle mit Zugriff auf den Speicher wird zum Angriffsvektor.

Angriffspfad 1: BitLocker ohne Pre-Boot-Authentifizierung

Sehr viele Unternehmensgeräte laufen mit BitLocker im Modus TPM-only. Das ist bequem, weil der Nutzer beim Start keine PIN eingeben muss. Das TPM gibt den Schlüssel frei, sobald die Messwerte der Boot-Kette stimmen. Der Schlüssel landet also ohne menschliches Zutun im Speicher, und wer die Boot-Kette geschickt manipuliert oder den Weg des Schlüssels beobachtet, kann ihn abgreifen. Microsoft räumt in der Dokumentation zu den BitLocker-Gegenmaßnahmen selbst ein, dass ohne Pre-Boot-Authentifizierung DMA- und Speicherangriffe möglich bleiben.

Das prominenteste Beispiel der letzten Jahre ist bitpixie (CVE-2023-21563). Thomas Lambertz hat auf dem 38C3 gezeigt, wie sich BitLocker im TPM-only-Modus ohne Schraubenzieher umgehen lässt. Über einen PXE-Netzwerkboot lädt der Angreifer einen alten, noch signierten Windows Boot Manager, der beim Soft-Reboot den Volume Master Key nicht aus dem Speicher löscht. Ein anschließend gebootetes Linux liest den Schlüssel aus. Das funktioniert auch auf vollständig gepatchten Systemen, solange Secure Boot dem alten Boot Manager noch vertraut. Der eigentliche Fix ist der Wechsel auf das Windows UEFI CA 2023-Zertifikat samt DBX-Update (KB5025885), den in der Praxis längst nicht jede Flotte vollzogen hat.

Brisant ist das gerade jetzt, denn das Zertifikat Windows Production PCA 2011, mit dem die alten Boot Manager signiert sind, läuft am 19. Oktober 2026 ab. Das Ablaufdatum allein entzieht den alten Boot Managern aber nicht das Vertrauen, die Geräte starten normal weiter. Die Lücke schließt erst die DBX-Sperrung.

Bei Geräten mit diskretem TPM-Chip kommt TPM-Sniffing hinzu. Die Kommunikation zwischen CPU und TPM läuft dort in der Regel unverschlüsselt über den LPC-, SPI- oder I²C-Bus. Firmware-TPMs, die in die CPU integriert sind, betrifft das nicht. Mit einem günstigen Logic Analyzer lässt sich der Schlüssel beim Booten mitlesen. Das braucht ein geöffnetes Gehäuse und je nach Mainboard Löterfahrung oder passende Prüfklemmen, aber kein Spezialwissen, das über öffentliche Anleitungen hinausgeht.

Angriffspfad 2: Gerät im Sleep-Modus und DMA

Liegt das Notebook zugeklappt im Standby, ist der Datenträger offen. Hier prüfen wir, ob externe Schnittstellen direkten Speicherzugriff erlauben. PCIe-Hotplug-Ports wie Thunderbolt und USB4 sind dafür der klassische Weg. Moderne Windows-Geräte bringen mit Kernel DMA Protection einen wirksamen Schutz über die IOMMU mit. Peripherie ohne DMA-Remapping-fähige Treiber wird bei gesperrtem Bildschirm blockiert. Ob der Schutz tatsächlich aktiv ist, hängt allerdings von Firmware-Unterstützung und der Virtualisierungsoption (VT-d) im UEFI ab, und er greift erst, wenn das Betriebssystem geladen ist. Das prüfen wir am konkreten Gerät.

Hinzu kommen Angriffe auf den Sperrbildschirm und die Wiederherstellungsumgebung (WinRE), wie der BitLocker-Bypass CVE-2024-20666 gezeigt hat, sowie präparierte USB-Geräte, die sich als Tastatur oder Netzwerkkarte ausgeben. Bei offenem Speicher kann schon eine solche Lücke für den Vollzugriff reichen.

Angriffspfad 3: Firmware, Bootreihenfolge und lokale Konfiguration

Oft fehlt schlicht ein BIOS/UEFI-Passwort, der Boot von USB ist erlaubt oder Secure Boot deaktiviert bzw. im Setup Mode. Ein fremdes System zu starten, reicht bei intaktem BitLocker allein noch nicht, weil das TPM bei veränderter Boot-Kette den Schlüssel nicht freigibt. Ist BitLocker aber nach einem Firmware- oder Systemupdate noch angehalten, liegt der Schlüssel im Klartext auf dem Datenträger, und die Daten sind offen. Selbst ohne Entschlüsselung lassen sich Firmware-Version, Secure-Boot-Datenbanken und Bootkonfiguration auslesen. Daraus ergibt sich, welche bekannten Bypässe auf diesem Gerät überhaupt in Frage kommen.

Gelingt der Zugriff auf das Dateisystem, suchen wir nach allem, was sich weiterverwenden lässt. Ergiebig sind meist lokale Kopien von OneDrive- und SharePoint-Inhalten, Skripte mit Passwörtern, SSH-Schlüssel, VPN-Profile, zwischengespeicherte Domänen-Anmeldedaten (bei schwachen Passwörtern offline knackbar) und die Hashes lokaler Konten. Browser-Passwörter und Cookies sind dagegen über DPAPI an das Benutzerpasswort gebunden und offline nicht ohne Weiteres lesbar.

Vom Laptop ins Unternehmensnetz

Auf Geräten mit TPM sind die Schlüssel hinter dem Primary Refresh Token und oft auch hinter dem Gerätezertifikat an das TPM gebunden und lassen sich nicht einfach kopieren. Wer aber Code auf dem Gerät selbst ausführen kann, etwa nach einem DMA-Angriff auf das gesperrte Gerät, kann sie unter Umständen direkt dort nutzen. Für Entra ID ist das dann ein registriertes, konformes Gerät, und das Szenario mündet in Szenario 1. Ein Always-On-VPN mit Gerätetunnel verbindet sich zudem schon vor der Anmeldung.

Deshalb schauen wir auch auf die Organisation. Wie schnell wird ein Verlust gemeldet, und wer sperrt das Gerät in Intune und widerruft Zertifikate und Sessions? Bleibt das Gerät offline, kommt auch der Remote Wipe nie an.

Dazu kommt die Frage, ob eine Meldung an die Aufsichtsbehörde nach Art. 33 DSGVO nötig ist, die möglichst binnen 72 Stunden erfolgen muss. Verschlüsselung spielt dabei auch rechtlich eine Rolle, weil Art. 34 Abs. 3 lit. a DSGVO sie ausdrücklich als Grund nennt, warum eine Benachrichtigung der Betroffenen entfallen kann. Das gilt allerdings nur, wenn sie tatsächlich wirksam ist.

Wie ein Lost-Device-Pentest abläuft

Wir testen ein Gerät, das exakt dem Standard-Image und der Standard-Hardware Ihrer Flotte entspricht, dazu ein Testkonto mit den Rechten eines normalen Mitarbeiters. Für Szenario 2 testen wir das Gerät ausgeschaltet und im Sleep-Modus. Vorab legen wir fest, wie invasiv getestet werden darf, also ob das Gehäuse geöffnet und am Mainboard gearbeitet werden darf. Der Test selbst umfasst typischerweise:

1. Szenario 1: Anmeldung mit dem Testkonto, Rechteausweitung, Cloud- und AD-Zugriffe
2. Test des Sperr- und Widerrufsprozesses mit Messung, wie lange Zugriffe nach der Meldung noch funktionieren
3. Szenario 2: Analyse von Firmware-Konfiguration, Secure-Boot-Status und Bootreihenfolge
4. Prüfung der BitLocker-Schutzmethode und bekannter Bypässe wie bitpixie
5. DMA- und Schnittstellentests am gesperrten Gerät
6. Hardwarenahe Angriffe wie TPM-Sniffing, sofern freigegeben
7. Auswertung extrahierter Daten und Prüfung, wie weit sie ins Netz und in die Cloud tragen

Am Ende steht eine Bewertung Ihrer konkreten Konfiguration, also was ein Angreifer in einer halben Stunde erreicht und was mit mehr Zeit und Werkzeug. Als Referenz für die Bewertung dienen unter anderem der Baustein SYS.3.1 Laptops aus dem BSI IT-Grundschutz-Kompendium (Edition 2023) und NIST SP 800-111 zur Datenträgerverschlüsselung auf Endgeräten.

Die wirksamsten Gegenmaßnahmen

Gegen Szenario 1 helfen vor allem Credential Guard, Windows LAPS, Benutzer ohne lokale Adminrechte und CAE-fähige Anwendungen. In der Öffentlichkeit ist biometrische Anmeldung besser als die PIN, denn ein Gesicht lässt sich nicht über die Schulter mitlesen.

Gegen Szenario 2 ist die Pre-Boot-Authentifizierung fast immer der größte Hebel. BitLocker mit TPM und PIN macht bitpixie, TPM-Sniffing und die meisten Boot-Ketten-Angriffe auf ein ausgeschaltetes Gerät wirkungslos. Wer das aus Usability-Gründen nicht flächendeckend will, sollte es zumindest für Führungskräfte, Admins und Reisende durchsetzen. Dazu gehören die Umstellung auf das neue Secure-Boot-Zertifikat samt Sperrung alter Boot Manager, ein gesetztes Firmware-Passwort, deaktivierter Boot von externen Medien und eine nachweislich aktive Kernel DMA Protection. Statt Standby empfiehlt sich für mobile Geräte der Ruhezustand (Hibernate). Das wirkt allerdings nur zusammen mit einer PIN, denn ohne Pre-Boot-Authentifizierung gibt das TPM den Schlüssel beim Aufwachen automatisch wieder frei.

Organisatorisch braucht es einen einfachen Meldeweg für Verluste, einen dokumentierten Ablauf zum Sperren von Gerät, Konto und Tokens und regelmäßige Kontrollen, ob die Härtung wirklich auf allen Geräten greift.

Fazit

Hat der Angreifer die Zugangsdaten, entscheidet vor allem, wie schnell gesperrt wird. Ohne Zugangsdaten hängt es an Details der BitLocker- und Firmware-Konfiguration, die im Alltag niemand sieht, und bitpixie hat gezeigt, dass "BitLocker ist an" dafür nicht reicht. Ein Lost-Device-Pentest prüft am realen Gerät, ob ein verlorener Laptop ein ärgerlicher Sachschaden bleibt oder zum Einstieg ins Unternehmensnetz wird. Wenn Sie wissen möchten, wie Ihre Client-Flotte in beiden Szenarien abschneidet, sprechen Sie uns zu einem Penetrationstest an.