
VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die PIN abfängt, die ihn entsperrt. Am 20. Mai 2026 von PhishU demonstriert, zeigt der Angriff, wie ein einziges sechsstelliges Geheimnis — während einer Adversary-in-the-Middle-Phishing-Sitzung (AiTM) abgefangen — einem Angreifer Zugang zu jedem synchronisierten Passwort und Passkey verschaffen kann, den ein Opfer im Google Passwortmanager gespeichert hat.
Für Unternehmen ist das Risiko größer als es erscheint. Der Browser-Tresor eines einzelnen Mitarbeiters kann SSO-Anmeldedaten, Cloud-Konsolen-Zugang, Logins für Finanzplattformen und Code-Repository-Schlüssel enthalten: alles an einem Ort und durch eine einzige abgefangene PIN offengelegt. Dies ist ein organisatorisches Risiko, das außerhalb der meisten bestehenden Incident-Response-Playbooks liegt und außerhalb der Sichtbarkeit der meisten IT- und Sicherheitsteams.
Wichtigste Erkenntnisse
VaultJacking ist relevant, weil Browser-Passwortmanager Passwörter, Passkeys und Wiederherstellungsabläufe in einem einzigen hochwertigen Ziel konzentrieren. Bevor Sie weiterlesen, hier das Wichtigste:
- VaultJacking zielt auf die Tresor-Synchronisierungsebene. Der Angriff bricht nicht die WebAuthn-Kryptographie. Er missbraucht den Geräteregistrierungsablauf, der bestimmt, wer den synchronisierten Tresor lesen kann.
- Die Google-Passwortmanager-PIN ist ein Tresor-Zugangsgeheimnis. Google verwendet die PIN zum Schutz verschlüsselter Anmeldedaten. Behandeln Sie sie entsprechend — nicht als belanglosen Code.
- Eine abgefangene PIN kann den gesamten Tresor offenlegen. Die Demonstration von PhishU zeigt, dass eine einzige PIN-Eingabe einem Angreifer ermöglichen kann, jedes synchronisierte Passwort und jeden Passkey auf einer vom Angreifer kontrollierten Infrastruktur zu entschlüsseln.
- Das Unternehmensrisiko skaliert mit Governance-Lücken. Die Vermischung von persönlichen und beruflichen Profilen, nicht verwaltete Chrome-Profile und privilegierte Anmeldedaten in Browser-Tresoren erhöhen den Schadensradius.
- Die Incident Response muss über einen Passwortwechsel hinausgehen. Ein vermutetes VaultJacking-Ereignis erfordert die Überprüfung von Geräten, Sitzungen, Passkeys, Tresorinhalten und nachgelagerten Logins — nicht nur das Ändern eines Passworts.
Was ist VaultJacking?
VaultJacking ist eine Phishing-Technik, die auf den Tresor-Zugang und die Wiederherstellungserfahrung des Google Passwortmanagers abzielt. Anstatt eine einzelne Website-Anmeldung zu stehlen, fängt der Angreifer die Google-Passwortmanager-PIN während einer AiTM-Phishing-Sitzung ab und verwendet sie, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben. Dadurch erhält er Zugang zum gesamten synchronisierten Anmeldedaten-Tresor. Der Begriff und die End-to-End-Demonstration stammen aus der veröffentlichten Forschung von PhishU.
Traditionelles Credential-Phishing zielt auf ein Konto nach dem anderen. VaultJacking ist eine andere Angriffsklasse: Der Angreifer umgeht einzelne Anmeldedaten vollständig und greift direkt auf das Repository zu, das alle enthält.
Die Forschung von PhishU beschreibt den Angriff als vollständig konsistent mit Standard-AiTM-Phishing. Der AiTM-Proxy fängt die PIN zusammen mit Session-Cookies ab. Ein Hintergrundprozess fügt dann einen Passkey des Angreifers zum Google-Konto des Opfers für Persistenz hinzu, tritt der Sicherheitsdomäne von der Angreifer-Infrastruktur aus mit der abgefangenen PIN bei und entschlüsselt den gesamten Tresor. Der Betreiber sieht alle synchronisierten Anmeldedaten in einer einzigen Ansicht.
Phishing vs. VaultJacking
Phishing
VaultJacking
Browser Syncjacking, eine separate Technik, auf die PhishU verweist, erreicht dieselbe Google-Sync-Ebene über eine bösartige Browser-Erweiterung. VaultJacking erfordert weder einen Geräte-Zugang noch eine Erweiterung.
Was ist die Google-Passwortmanager-PIN?
Die Google-Passwortmanager-PIN ist ein separates Geheimnis, das sich von Ihrem Google-Kontopasswort und Ihrer Geräte-Bildschirmsperre unterscheidet. Googles Dokumentation beschreibt sie als eine Möglichkeit, verschlüsselte Google-Passwortmanager-Daten zu schützen, Passkeys auf einem neuen Gerät zu verwenden und die Identität zu verifizieren.
Benutzer verwechseln häufig drei verschiedene Geheimnisse, und diese Verwirrung ist Teil dessen, was VaultJacking so effektiv macht:
| Geheimnis | Was es ist | Warum die Verwechslung relevant ist |
|---|---|---|
| Google-Kontopasswort | Die Anmeldedaten für die Anmeldung bei einem Google-Konto | Benutzer geben möglicherweise dieses ein, wenn sie nach einer PIN gefragt werden, ohne den Unterschied zu bemerken |
| Geräte-Bildschirmsperre | Eine lokale PIN, ein Passcode, biometrische Daten oder ein Muster, das das Gerät entsperrt | Passkeys verwenden oft die Geräte-Entsperrung, aber diese ist nicht identisch mit der Google-Passwortmanager-PIN |
| Google-Passwortmanager-PIN | Eine PIN, die verschlüsselte Google-Passwortmanager-Daten schützt und in Tresor-Zugangs- und Geräteregistrierungsabläufen verwendet wird | VaultJacking zielt speziell auf dieses Geheimnis ab |
Die Aufforderung zur Eingabe der Google-Passwortmanager-PIN erscheint beim Erstellen Ihres ersten Passkeys auf einem neuen Gerät, beim Zugriff auf verschlüsselte gespeicherte Anmeldedaten in bestimmten Wiederherstellungskontexten oder wenn ein neues Gerät Ihrer Google-Sicherheitsdomäne beitritt. Das letzte Szenario ist genau das, was VaultJacking ausnutzt.
Der strukturelle Grund, warum dies funktioniert, liegt laut der Analyse von PhishU des Chromium-Quellcodes (chrome/browser/webauthn/enclave_manager.cc und components/trusted_vault/) darin, dass Googles Sicherheitsdomänen-Beitrittsablauf zwei Prüfungen erfordert: eine Google-Kontoanmeldung und eine erfolgreiche PIN-Eingabe. Es gibt keine geräteübergreifende Genehmigungsaufforderung, keine Push-Benachrichtigung an bestehende Geräte, keine „Von einem anderen Gerät genehmigen"-Bestätigung.
Apples iCloud-Schlüsselbund erfordert, dass bestehende Geräte neue genehmigen. Googles Modell nicht. Google hat einen bewussten UX-Kompromiss getroffen: Eine PIN mit einem serverseitigen Wiederholungslimit ist einfacher zu handhaben als ein Push-to-Approve-Modell, wenn ein Benutzer alle seine Geräte verloren hat. VaultJacking ist die Konsequenz dieses Kompromisses.
Wie die VaultJacking-Angriffskette funktioniert
Das Folgende beschreibt den Angriff konzeptionell für Verteidigungszwecke. Es sind keine offensiven Implementierungsdetails enthalten.
- Köder. Das Opfer erhält einen Phishing-Link und landet auf einer Seite, die einen legitimen Google-Anmelde- oder Kontoablauf imitiert. Behandeln Sie jeden unerwarteten Anmeldeablauf, der per E-Mail, Chat oder Werbelink ankommt, mit Misstrauen.
- Vertrauenstransfer. Der AiTM-Proxy rendert eine PIN-Aufforderung, die dem Stil von Googles eigener Oberfläche entspricht: gleiche Schriftart, gleiche sechs-Zellen-Eingabe, gleicher Text. Die Benutzerschulung muss Passwortmanager-PIN-Aufforderungen abdecken, nicht nur Passwörter und OTP-Codes.
- PIN-Abfang. Das Opfer gibt die PIN in den Phishing-Ablauf ein. Die PIN ist ein Tresor-Zugangsgeheimnis, das in seiner Sensibilität einem Masterpasswort entspricht.
- Angreifer-Geräteregistrierung. Der Angreifer verwendet die abgefangene PIN, um der Google-Sicherheitsdomäne des Opfers von einer vom Angreifer kontrollierten Infrastruktur aus beizutreten. Ein Passkey des Angreifers wird ebenfalls für Persistenz registriert. Überprüfen Sie angemeldete Geräte und registrierte Passkeys sofort nach jedem vermuteten Phishing-Kontakt.
- Tresor-Entschlüsselung. Das Security Domain Secret wird von Googles Cloud-Authenticator freigegeben, und das Gerät des Angreifers entschlüsselt jedes synchronisierte Passwort und jeden Passkey. Der Tresor kann Anmeldedaten für E-Mail, SSO, Cloud-Konsolen, Finanzplattformen und Code-Repositories enthalten.
- Nachgelagerte Kompromittierung. Gespeicherte Drittanbieter-Anmeldedaten werden gegen andere Dienste verwendet. Rotieren Sie hochwertige Anmeldedaten und überwachen Sie Drittanbieter-Logins.
PhishU hat dies End-to-End gegen Live-Google-Passwortmanager-Konten getestet, einschließlich der Wiedergabe von abgefangenen Drittanbieter-Passkeys, unabhängig davon, ob die ursprünglichen Anmeldedaten hardwaregestützt waren. Behandeln Sie dies als eine demonstrierte Technik. Es gibt zum Zeitpunkt des Schreibens keine öffentlichen Beweise für eine weit verbreitete aktive Ausnutzung, aber die Technik erfordert keinen spezialisierten Zugang oder Geräte-Zugriff.
Bedeutet VaultJacking, dass Passkeys unsicher sind?
Nein. VaultJacking bricht nicht die Passkey-Kryptographie. Passkeys basieren auf ursprungsgebundener Public-Key-Authentifizierung, wie in der W3C WebAuthn-Spezifikation definiert: Der private Schlüssel verlässt niemals das Gerät, und die Authentifizierungszeremonie ist an den legitimen Website-Ursprung gebunden. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsprüfung fehlschlägt. Dieser Schutz bleibt bestehen.
Was VaultJacking demonstriert, ist, dass Passkeys nicht isoliert existieren. Sie existieren in einem Tresor, der über Geräte synchronisiert wird, der auf einem Wiederherstellungsmechanismus basiert, der durch eine PIN gesteuert wird. Der Angreifer umgeht die kryptographische Zeremonie vollständig, indem er stattdessen auf die Tresor-Verwaltungsebene abzielt.
Google beschreibt Passkeys als eine Möglichkeit, sich mit Fingerabdruck, Gesichtserkennung oder Bildschirmsperre anzumelden — einfacher und sicherer als Passwörter. Diese Beschreibung ist auf der Ebene der Einzelsite-Authentifizierung korrekt. Das Problem, das VaultJacking aufzeigt, liegt eine Ebene höher: Was steuert den Zugang zum Speicher, der diese Passkeys enthält.
| Ebene | Normaler Schutz | VaultJacking-Relevanz |
|---|---|---|
| WebAuthn-Authentifizierung | Ursprungsgebundene Public-Key-Kryptographie verhindert die Wiedergabe von Anmeldedaten auf Phishing-Seiten | Der Angriff muss keine wiederverwendbaren Passkey-Anmeldedaten stehlen |
| Google-Passwortmanager-Tresor | Verschlüsselte Speicherung mit PIN-geschützter Wiederherstellung | Der Angreifer zielt auf die PIN und den Geräteregistrierungsablauf rund um den Tresor ab |
| Benutzeroberfläche | Benutzer vertrauen Browser- und Google-Aufforderungen | Phishing missbraucht dieses Vertrauen, indem es legitime PIN-Aufforderungen imitiert |
| Unternehmens-Governance | Administratoren können die Browser-Profilnutzung und gespeicherte Anmeldedaten kontrollieren oder auch nicht | Schlechte Governance erhöht den Schadensradius nach einer Tresor-Kompromittierung |
Warum eine PIN einen großen Schadensradius erzeugen kann
Ein Passwortmanager-Tresor ist ein konzentrierter Speicher für Zugang. Eine abgefangene PIN legt alle Anmeldedaten offen, die das Opfer jemals im Google Passwortmanager gespeichert hat.
Der Identity Threat Landscape Report 2025 von Recorded Future stellte fest, dass das durchschnittliche kompromittierte Gerät 87 gestohlene Anmeldedaten ergab und dass 276 Millionen der 2025 indexierten Anmeldedaten aktive Session-Cookies enthielten — was bedeutet, dass Angreifer MFA für diese Konten vollständig umgehen konnten.
Verizons DBIR 2026 setzt die nachgelagerten Auswirkungen in einen Kontext: Der Missbrauch von Anmeldedaten erscheint irgendwann in 39 % aller bestätigten Sicherheitsverletzungen, über mehr als 22.000 Vorfälle in 145 Ländern hinweg. Angreifer bleiben selten bei der ersten Tür stehen, die gestohlene Anmeldedaten öffnen. Sie bewegen sich lateral, eskalieren Privilegien und arbeiten sich durch jeden gespeicherten Login, bis sie etwas Wertvolles finden.
| Tresor-Inhaltstyp | Potenzielles nachgelagertes Risiko |
|---|---|
| E-Mail- und SSO-Anmeldedaten | Missbrauch der Kontowiederherstellung, laterale Bewegung, Identitätsübernahme |
| Cloud-Konsolen-Anmeldedaten | Infrastrukturzugang, Privilegien-Eskalation, Datenexposition |
| Code-Repository-Anmeldedaten | Quellcode-Diebstahl, CI/CD-Pipeline-Kompromittierung, Offenlegung von Secrets |
| Finanz- und Gehaltsabrechnungs-Anmeldedaten | Betrug, Rechnungsmanipulation, Zahlungsumleitung |
| Persönliche Konten gemischt mit Arbeitsprofilen | Nicht verwalteter Expositionspfad in Geschäftssysteme |
| Gespeicherte Passkeys | Das Risiko hängt vom Synchronisierungsstatus, den Wiederherstellungskontrollen und der Geräteregistrierungsrichtlinie ab |
Wer ist am stärksten gefährdet?
Das Risiko konzentriert sich dort, wo drei Bedingungen zusammentreffen: Browser-Tresor-Daten sind der primäre Anmeldedatenspeicher, Arbeits- und persönliche Anmeldedaten teilen ein Profil, und privilegierte Anmeldedaten sind in einem Consumer-System gelandet.
- Das Problem der Vermischung von Anmeldedaten. Mitarbeiter speichern Arbeits-Anmeldedaten in persönlichen Chrome-Profilen. Administratoren haben keine Sichtbarkeit oder Kontrolle über Tresorinhalte oder synchronisierte Geräte. Dies bedeutet, dass Unternehmenspasswörter außerhalb des Sicherheitsperimeters leben, auf Googles Servern gesichert werden und von jedem Gerät aus zugänglich sind, bei dem sich der Mitarbeiter jemals angemeldet hat.
- Privilegierte Benutzer sind das hochwertigste Ziel. Im Google Passwortmanager gespeicherte Admin-Passwörter stellen die gefährlichste Risikokonzentration dar. Eine Tresor-Kompromittierung legt die Schlüssel zu Identitätsplattformen, Cloud-Infrastruktur, Finanzsystemen und Sicherheits-Tools offen. Ein einziges kompromittiertes Admin-Konto wird zum Drehpunkt für laterale Bewegung in der gesamten Organisation.
- Sicherheitstraining deckt diese Angriffsfläche nicht ab. Security-Awareness-Programme lehren Benutzer, Phishing-E-Mails zu erkennen und OTP-Codes zu schützen. Sie lehren Benutzer nicht, Passwortmanager-PIN-Aufforderungen als sensible Ziele zu erkennen. Benutzer sehen eine PIN-Anfrage und kommen ihr nach — sie sehen es nicht als ein Sicherheitsereignis, das Skepsis auslösen sollte.
- Richtlinienlücken lassen Anmeldedaten am falschen Ort. Die meisten Organisationen haben keine Richtlinie, die Browser-Tresore von der Unternehmens-Anmeldedatenverwaltung trennt. Geteilte Anmeldedaten, Admin-Passwörter und Break-Glass-Konten werden möglicherweise dort gespeichert, wo es Mitarbeitern bequem erscheint. Es existiert kein Audit-Trail, der zeigt, wo diese Anmeldedaten liegen oder wer darauf zugegriffen hat.
- Geräte- und Sitzungsüberprüfungsprozesse sind zu langsam. Verdächtige Geräteregistrierungen oder Tresorzugriffe können wochenlang unbemerkt bleiben.
Der letzte Punkt ist wichtiger, als es erscheinen mag. PhishU merkt an, dass Google eine einzige E-Mail „Neue Anmeldung unter Windows" sendet, wenn ein neues Gerät der Sicherheitsdomäne beitritt — dieselbe Benachrichtigung, die für jede neue Chrome-Anmeldung gesendet wird. Auf bestehenden Geräten wird keine Push-Benachrichtigung ausgelöst. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.
Was zu tun ist, wenn eine Google-Passwortmanager-PIN möglicherweise gephisht wurde
Behandeln Sie ein vermutetes VaultJacking-Ereignis nicht als Einzelpasswort-Vorfall. Behandeln Sie es als mögliche Tresor-Exposition, bis das Gegenteil bewiesen ist.
Die folgende Triage-Sequenz richtet sich an Sicherheitsteams und Einzelpersonen. Google-Workspace-Ereignisnamen sollten anhand der aktuellen Google-Admin-Dokumentation überprüft werden, bevor eine automatisierte Erkennung erstellt wird.
| Priorität | Maßnahme | Warum es wichtig ist |
|---|---|---|
| 1 | Trennen Sie die Verbindung zur verdächtigen Phishing-Seite; sichern Sie die URL, den Zeitstempel und Screenshots, wenn dies sicher möglich ist | Beweise helfen, den Umfang zu bestimmen und andere Benutzer zu warnen |
| 2 | Überprüfen Sie die Sicherheitsaktivität des Google-Kontos, angemeldete Geräte und kürzlich hinzugefügte Passkeys unter myaccount.google.com | Tresor- oder Geräteregistrierung könnte Angreifer-Persistenz geschaffen haben |
| 3 | Melden Sie verdächtige Sitzungen ab und widerrufen Sie unbekannte Geräte | Reduziert den Angreiferzugang, falls das Konto oder der Tresor erreicht wurde |
| 4 | Ändern Sie das Google-Kontopasswort, wenn eine Kompromittierung auf Kontoebene vermutet wird | Verhindert weiteren Zugang auf Kontoebene; notwendig, aber allein nicht ausreichend |
| 5 | Rotieren Sie hochwertige Anmeldedaten, die im Tresor gespeichert sind | Priorisieren Sie SSO, E-Mail, Cloud-Konsolen, Finanzplattformen, Admin-Konten, VPNs, Code-Repositories und alle Passwortmanager-Konten |
| 6 | Überprüfen Sie Drittanbieterdienste auf ungewöhnliche Login-Aktivitäten | Angreifer können gespeicherte Anmeldedaten außerhalb von Google sofort nach dem Tresorzugang verwenden |
| 7 | Für Organisationen: Eröffnen Sie einen Incident-Response-Fall und überprüfen Sie Geräte-, Identitäts- und Browser-Telemetrie | Ein einzelner betroffener Benutzer kann organisatorische Exposition verursachen, wenn er privilegierte Anmeldedaten besitzt |
| 8 | Überprüfen Sie die Browser-Tresor-Richtlinie und die Speicherpraktiken für privilegierte Anmeldedaten | Verhindert wiederholte Vorfälle und reduziert den zukünftigen Schadensradius |
Die Schritte 5 und 7 sind dort, wo die meisten Incident Responses zu kurz greifen. Das Google-Kontopasswort zu rotieren, ohne die nachgelagerten Anmeldedaten zu rotieren, die es schützt, ist wie das Schloss an einem Safe zu wechseln, nachdem der Inhalt bereits fotografiert wurde.
Passwork gibt Ihnen Einblick in alle Anmeldedaten, wer darauf zugegriffen hat und wann. Rollenbasierter Zugriff bedeutet, dass geteilte Anmeldedaten an einem Ort mit vollständigem Audit-Trail bleiben — nicht über persönliche Browser-Profile verstreut. Erfahren Sie, wie es funktioniert
Wie Einzelpersonen das VaultJacking-Risiko reduzieren können
Der praktische Rat hier ist kurz. Das meiste läuft darauf hinaus, die Google-Passwortmanager-PIN genauso zu behandeln wie ein Masterpasswort.
- Geben Sie die Google-Passwortmanager-PIN nicht auf einer Seite ein, die Sie durch Klicken auf einen Link in einer E-Mail, einem Chat oder einer Werbung erreicht haben. Navigieren Sie direkt zu den Google-Kontoeinstellungen.
- Überprüfen Sie Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com regelmäßig. Ein unbekanntes Gerät oder ein unbekannter Passkey ist eine Untersuchung wert.
- Halten Sie persönliche und berufliche Browser-Profile getrennt. Wenn ein persönliches Profil kompromittiert wird, sollten Arbeits-Anmeldedaten nicht im Schadensradius sein.
- Vermeiden Sie das Speichern hochsensibler Admin- oder privilegierter Anmeldedaten in einem Consumer-Browser-Tresor. Diese Anmeldedaten benötigen Auditierbarkeit und Zugriffskontrollen, die Browser-Tresore nicht bieten.
- Verwenden Sie weiterhin Passkeys. Sie bleiben auf der Einzelsite-Ebene sicherer als wiederverwendbare Passwörter. Verstehen Sie nur, welche Aufforderungen legitim sind und welche nicht.
Unternehmenskontrollen und Richtlinienempfehlungen
Oktas Secure Sign-in Trends Report 2025 stellte fest, dass die Einführung von phishing-resistenten Authentifikatoren in einem Jahr von 8,6 % auf 14,0 % der Benutzer wuchs — ein Anstieg von 63 %. Dieses Wachstum ist eine gute Nachricht. Das Governance-Problem ist, dass Organisationen Passkeys schneller einführen, als sie die Richtlinien zur Verwaltung der Tresore aufbauen, die sie speichern.
Die folgenden Kontrollen sind proportional zur Sensibilität der beteiligten Anmeldedaten. Nicht jede Organisation benötigt jede Kontrolle, aber jede Organisation, die privilegierte Anmeldedaten in Browser-Tresoren speichert, benötigt eine Richtlinie, die dies speziell adressiert.
- Browser-Profil-Governance. Erzwingen Sie separate verwaltete Arbeitsprofile. Entmutigen Sie die Vermischung von persönlichen und Arbeits-Tresoren durch Richtlinien und Benutzerschulung.
- Speicherung privilegierter Anmeldedaten. Verbieten Sie das Speichern von Admin-, Break-Glass-, Cloud-Root-, Finanz- und Service-Account-Anmeldedaten in nicht verwalteten Browser-Tresoren. Browser-Tresore sind bequem für die persönliche Nutzung. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.
- Enterprise-Passwort-Management. Verwenden Sie einen dedizierten Enterprise-Passwortmanager für geteilte, privilegierte und auditierte Anmeldedaten. Passwork ist eine selbst gehostete Lösung, die genau für diese Trennung entwickelt wurde: privilegierte Anmeldedaten in einem kontrollierten, auditierbaren Tresor mit rollenbasierter Zugriffskontrolle, AD/LDAP-Integration und vollständigem Audit-Log.
- Phishing-resistente MFA. Setzen Sie die Einführung von WebAuthn und FIDO2 fort. Erweitern Sie die Benutzerschulung auf Wiederherstellungsabläufe und Tresor-Aufforderungen, nicht nur auf Passwörter und OTP-Codes.
- Geräte- und Sitzungssichtbarkeit. Überwachen Sie auf unbekannte Geräteregistrierungen, ungewöhnliche Sitzungsaktivitäten und unerwartete Kontosicherheitsänderungen. Google sendet eine „Neue Anmeldung"-E-Mail für jede neue Chrome-Anmeldung. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.
- Incident Response. Erstellen Sie ein Tresor-Expositions-Runbook, das Anmeldedaten-Rotation, Sitzungswiderruf, Passkey-Überprüfung und Drittanbieter-Kontoüberwachung umfasst.
- Security Awareness. Schulen Sie Benutzer, dass PINs, Passwortmanager-Aufforderungen und Wiederherstellungsabläufe Phishing-Ziele sind. Sie tragen dasselbe Risiko wie Passwörter und OTP-Codes.
Der Punkt zum Enterprise-Passwortmanager verdient Betonung. Browser-Tresore sind bequem und verbessern die Passwort-Einzigartigkeit für viele Benutzer. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.
Warum ein Enterprise-Passwortmanager sicherer ist als ein Browser-Tresor für Arbeits-Anmeldedaten

Ein Browser-Passwortmanager löst ein persönliches Komfortproblem: Autofill, Gerätesynchronisation, mühelose Speicherung. Für einen einzelnen Benutzer ist das eine vernünftige Wahl. Für eine Unternehmensumgebung wird dieselbe Einfachheit zu einer strukturellen Schwachstelle.
Passwork ist die Enterprise-Alternative zu persönlichen Browser-Tresoren. Die Passwork-Browser-Erweiterung funktioniert genau wie ein integrierter Browser-Passwortmanager — sie füllt Logins auf Websites automatisch aus, bietet an, neue Anmeldedaten zu speichern — speichert sie aber in einem geschützten Unternehmens-Tresor anstatt in einem persönlichen Browser-Profil.
Passwork unterstützt selbst gehostete Bereitstellung, AES-256-Verschlüsselung, Active Directory- und LDAP-Integration, SSO-Autorisierung, rollenbasierte Zugriffskontrolle, vollständiges Audit-Logging, SIEM-Integration sowie REST API- und CLI-Tools für DevOps-Workflows.
| Kriterium | Browser-Tresor | Passwork |
|---|---|---|
| Datenspeicherung | Server des Cloud-Anbieters | Eigene Infrastruktur des Unternehmens |
| Verschlüsselung | Vom Anbieter verwaltet; Schlüssel beim Anbieter | AES-256; Verschlüsselungsschlüssel beim Unternehmen |
| Autofill | Ja | Ja, über Browser-Erweiterung — identische Benutzererfahrung |
| Zugriffskontrolle | Keine — alle Benutzer sehen alle Anmeldedaten, auf die sie zugreifen können | Rollenbasiert: Mitarbeiter sehen nur ihre zugewiesenen Tresore und Ordner |
| Geteilte Team-Anmeldedaten | Manuell per Chat, E-Mail, Notizen weitergegeben | In geteilten Tresoren mit granularer Zugriffskontrolle gespeichert |
| Audit-Log | Keines | Vollständig: wer worauf zugegriffen hat, wann und was geändert wurde |
| Sichtbarkeit für das Sicherheitsteam | Keine — persönliches Profil außerhalb der Unternehmenskontrolle | Volle Sichtbarkeit: alle Tresore, Berechtigungen und Zugriffsereignisse |
| Infrastruktur-Integration | Keine | Active Directory, LDAP, SSO, SIEM, REST API, CLI |
| VaultJacking-Schutz | Anfällig: Eine einzige PIN legt den gesamten Tresor offen | Tresor vom Browser-Profil und persönlichen Konto isoliert |
| Regulatorische Compliance | Nicht verifiziert | ISO 27001, DSGVO, NIS2, SOC 2 zertifiziert |
Der Unterschied ist architektonisch. Ein Browser-Tresor priorisiert individuellen Komfort. Ein Enterprise-Passwortmanager priorisiert organisatorische Kontrolle und Sichtbarkeit. Wenn privilegierte Anmeldedaten in einem Browser-Tresor landen, wurde das falsche Werkzeug für die Aufgabe gewählt — nicht weil das Werkzeug schlecht ist, sondern weil es für ein anderes Problem konzipiert wurde.
Fazit: Was gegen VaultJacking zu tun ist

Die Bedrohung, die VaultJacking beschreibt, ist spezifisch: eine Phishing-Technik, die eine abgefangene PIN in tresorweite Anmeldedaten-Exposition verwandelt. Die Reaktion sollte ebenso spezifisch sein — keine Panik über Passkeys und keine Verharmlosung des Browser-Tresor-Risikos, sondern eine klare Richtlinie, die persönlichen Anmeldedaten-Komfort von privilegierter Anmeldedaten-Governance trennt.
Beginnen Sie mit dem Audit. Finden Sie heraus, welche privilegierten Anmeldedaten derzeit in Browser-Tresoren liegen. Welche Admin-Konten sind mit persönlichen Geräten synchronisiert? Welche Break-Glass-Anmeldedaten sind im Google Passwortmanager gespeichert? Diese Antwort wird Ihnen sagen, wie viel Arbeit noch zu tun ist.
Von dort aus ist der Weg klar: Verbieten Sie privilegierte Anmeldedaten in Browser-Tresoren, verschieben Sie sie in einen Enterprise-Passwortmanager mit Audit-Trails und Zugriffskontrollen, und erweitern Sie Ihr Security-Awareness-Training auf Tresor-Aufforderungen und Wiederherstellungsabläufe.
VaultJacking ist kein Grund, Browser-Passwortmanager aufzugeben. Es ist ein Grund, sie für das zu verwenden, wofür sie konzipiert wurden — persönliche Anmeldedaten — und ein separates, auditierbares System für alles andere aufzubauen.
Passwork ist ein selbst gehosteter Enterprise-Passwort- und Secrets-Manager, der für privilegierte Anmeldedaten-Governance entwickelt wurde. Er bietet rollenbasierten Zugriff, vollständige Audit-Logs und vollständige Trennung von Consumer-Browser-Tresoren. Erfahren Sie, wie er in Ihre Infrastruktur passt
Häufig gestellte Fragen

Was ist VaultJacking?
VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die Google-Passwortmanager-PIN des Benutzers während einer Adversary-in-the-Middle-Phishing-Sitzung abfängt. Die abgefangene PIN wird verwendet, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben, wodurch jedes synchronisierte Passwort und jeder Passkey im Tresor entschlüsselt wird. Die Technik wurde im Mai 2026 End-to-End von PhishU demonstriert.
Ist VaultJacking eine Google-Schwachstelle?
Basierend auf veröffentlichten Berichten ist VaultJacking eine demonstrierte Phishing- und Workflow-Missbrauchstechnik, keine klassifizierte Schwachstelle in Googles Systemen. Sie nutzt das Design von Googles Geräteregistrierungsablauf aus — insbesondere das Fehlen einer geräteübergreifenden Genehmigung für neue Sicherheitsdomänen-Beitritte — was Google bewusst als UX-Kompromiss für die Wiederherstellung bei verlorenem Gerät gewählt hat. Ob Google dies als Schwachstelle klassifiziert, die eine Behebung erfordert, ist eine separate Frage, die zum Zeitpunkt des Schreibens nicht öffentlich beantwortet wurde.
Bricht VaultJacking Passkeys?
Nein. Passkeys basieren auf ursprungsgebundener Public-Key-Kryptographie, wie in der W3C WebAuthn-Spezifikation definiert. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsbindung fehlschlägt. VaultJacking zielt auf den Tresor und die Wiederherstellungsebene ab, die Passkeys speichert — nicht auf die kryptographische Authentifizierungszeremonie selbst. Passkeys bleiben auf der Einzelsite-Login-Ebene phishing-resistent.
Was ist die Google-Passwortmanager-PIN?
Die Google-Passwortmanager-PIN ist ein Geheimnis, das verschlüsselte Google-Passwortmanager-Daten schützt. Laut Googles Dokumentation wird sie erstellt, wenn ein Benutzer seinen ersten Passkey auf einem Computer, iPhone oder iPad speichert, und sie wird verwendet, um auf Passkeys auf neuen Geräten zuzugreifen, die Identität zu verifizieren und sicherzustellen, dass nicht einmal Google den verschlüsselten Tresorinhalt lesen kann. Sie unterscheidet sich vom Google-Kontopasswort und von der Geräte-Bildschirmsperre.
Kann eine PIN alle meine gespeicherten Passwörter offenlegen?
Die Demonstration von PhishU zeigt, dass eine abgefangene sechsstellige Google-Passwortmanager-PIN einem Angreifer ermöglichen kann, den gesamten synchronisierten Tresor zu entschlüsseln — jedes gespeicherte Passwort und jeden synchronisierten Passkey — von einer vom Angreifer kontrollierten Infrastruktur aus. Die PIN gibt das Security Domain Secret frei, das den Tresor in einer einzigen Operation entschlüsselt. Wenn Sie die PIN auf einer Seite eingegeben haben, zu der Sie nicht direkt navigiert sind, behandeln Sie dies als mögliche vollständige Tresor-Exposition.
Was sollte ich tun, wenn ich die PIN auf einer verdächtigen Seite eingegeben habe?
Überprüfen Sie sofort Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com. Widerrufen Sie alle unbekannten Geräte oder Sitzungen. Ändern Sie Ihr Google-Kontopasswort. Rotieren Sie hochwertige Anmeldedaten, die im Tresor gespeichert sind — priorisieren Sie SSO, E-Mail, Cloud-Konsolen, Finanzplattformen und Admin-Konten. Überprüfen Sie Drittanbieterdienste auf ungewöhnliche Login-Aktivitäten. Wenn Sie in einer Organisation sind, eröffnen Sie einen Incident-Response-Fall, anstatt dies als Einzelkonto-Problem zu behandeln.
Sollten Unternehmen den Google Passwortmanager verbieten?
Ein pauschales Verbot ist für die meisten Organisationen nicht die richtige Richtlinie. Ein risikobasierter Ansatz funktioniert besser: Beschränken Sie die Speicherung privilegierter und geteilter Anmeldedaten auf einen Enterprise-Passwortmanager mit Audit-Kontrollen, erzwingen Sie separate verwaltete Browser-Profile für die Arbeit und erweitern Sie das Phishing-Awareness-Training auf Passwortmanager-Aufforderungen und Wiederherstellungsabläufe. Der Google Passwortmanager ist für persönliche Anmeldedaten geeignet; er ist nicht für Break-Glass-Konten oder geteilten Admin-Zugang konzipiert.
Reichen Hardware-Sicherheitsschlüssel aus, um dies zu stoppen?
Hardware-Sicherheitsschlüssel stärken die Sicherheitsgarantie bei der Google-Kontoanmeldung, aber sie steuern nicht automatisch die Browser-Tresor-Synchronisation, Wiederherstellungsabläufe oder die im Tresor gespeicherten Anmeldedaten. VaultJacking zielt auf die Tresor-Verwaltungsebene ab, nicht auf den Kontoanmeldeschritt. Ein Hardware-Schlüssel für das Google-Konto reduziert das Risiko einer Kontoübernahme, verhindert aber nicht, dass ein Benutzer dazu verleitet wird, seine Google-Passwortmanager-PIN auf einer Phishing-Seite einzugeben.



Inhaltsverzeichnis
- Wichtigste Erkenntnisse
- Was ist VaultJacking?
- Phishing vs. VaultJacking
- Was ist die Google-Passwortmanager-PIN?
- Wie die VaultJacking-Angriffskette funktioniert
- Bedeutet VaultJacking, dass Passkeys unsicher sind?
- Warum eine PIN einen großen Schadensradius erzeugen kann
- Wer ist am stärksten gefährdet?
- Was zu tun ist, wenn eine Google-Passwortmanager-PIN möglicherweise gephisht wurde
- Wie Einzelpersonen das VaultJacking-Risiko reduzieren können
- Unternehmenskontrollen und Richtlinienempfehlungen
- Warum ein Enterprise-Passwortmanager sicherer ist als ein Browser-Tresor für Arbeits-Anmeldedaten
- Fazit: Was gegen VaultJacking zu tun ist
- Häufig gestellte Fragen
Inhaltsverzeichnis
- Wichtigste Erkenntnisse
- Was ist VaultJacking?
- Phishing vs. VaultJacking
- Was ist die Google-Passwortmanager-PIN?
- Wie die VaultJacking-Angriffskette funktioniert
- Bedeutet VaultJacking, dass Passkeys unsicher sind?
- Warum eine PIN einen großen Schadensradius erzeugen kann
- Wer ist am stärksten gefährdet?
- Was zu tun ist, wenn eine Google-Passwortmanager-PIN möglicherweise gephisht wurde
- Wie Einzelpersonen das VaultJacking-Risiko reduzieren können
- Unternehmenskontrollen und Richtlinienempfehlungen
- Warum ein Enterprise-Passwortmanager sicherer ist als ein Browser-Tresor für Arbeits-Anmeldedaten
- Fazit: Was gegen VaultJacking zu tun ist
- Häufig gestellte Fragen
Self-hosted-Passwort-Manager für Ihr Unternehmen
Passwork bietet den Vorteil einer effektiven Teamarbeit mit Unternehmenspasswörtern in einer vollständig sicheren Umgebung
Mehr erfahren