Thought Leadership
Infostealer-Malware umgeht MFA durch den Diebstahl aktiver Session-Cookies. Ein Einblick in die Mechanismen von Session-Hijacking, DPoP und Token Binding.
Die flächendeckende Einführung der Multi-Faktor-Authentifizierung, kurz MFA, hat die klassische Passworteingabe als alleinige Absicherung digitaler Identitäten in Unternehmen weitgehend verdrängt. Durch den erzwungenen Einsatz von Einmalcodes, Push-Benachrichtigungen oder kryptografischen Hardware-Schlüsseln ist es für Angreifer erheblich schwerer geworden, IT-Systeme durch den reinen Diebstahl von Zugangsdaten zu kompromittieren. Diese erfolgreiche Härtung der Authentifizierungsphase hat jedoch im Jahr 2026 zu einer fundamentalen Anpassung der Angriffsstrategien im cyberkriminellen Ökosystem geführt.
Anstatt zu versuchen, den zweiten Faktor während des Anmeldevorgangs abzufangen oder zu umgehen, fokussieren sich kriminelle Akteure zunehmend auf die Phase nach der erfolgreichen Authentifizierung. Der Schwarzmarkt für spezialisierte Infostealer-Malware wie Lumma, Stealc oder Meduza verzeichnet ein exponentielles Wachstum. Diese Schadsoftware wird über Phishing-Kampagnen, manipulierte Suchmaschinenergebnisse oder kompromittierte Open-Source-Pakete auf die Endgeräte von Mitarbeitern geschleust. Das primäre Ziel dieser Programme ist nicht mehr das Ausspähen von Passwörtern, sondern die direkte Exfiltration aktiver Sitzungsdaten, der sogenannten Session-Cookies, direkt aus dem Speicherbereich des Webbrowsers.
Die technische Mechanik des Cookie-Diebstahls aus dem Browserspeicher
Webbrowser nutzen Session-Cookies und Zugriffstoken, um den Authentifizierungsstatus eines Nutzers über einen längeren Zeitraum hinweg aufrechtzuerhalten. Sobald ein Mitarbeiter den Anmeldevorgang inklusive MFA erfolgreich durchlaufen hat, stellt der Identitätsdienst des Unternehmens ein kryptografisch signiertes Token aus. Dieses Token wird im lokalen Speicher des Browsers, beispielsweise in den SQLite-Datenbanken des Benutzerprofils oder im LocalStorage, hinterlegt. Bei jeder nachfolgenden Anfrage sendet der Browser dieses Token automatisch im HTTP-Header mit, wodurch der Server den Nutzer als verifiziert erkennt, ohne bei jeder Aktion eine erneute Passworteingabe oder MFA-Abfrage zu verlangen.
Infostealer-Malware nutzt aus, dass diese lokalen Speicherstrukturen auf Betriebssystemebene oft unzureichend isoliert sind. Sobald die Schadsoftware im Kontext des Benutzers ausgeführt wird, greift sie direkt auf die Profilverzeichnisse von Browsern wie Google Chrome, Microsoft Edge oder Mozilla Firefox zu. Unter Windows sind diese Daten zwar häufig über die Data Protection API verschlüsselt, doch da die Schadsoftware mit den Rechten des angemeldeten Benutzers operiert, kann sie die Entschlüsselungsschlüssel direkt über die Betriebssystemschnittstellen abfragen.
Die extrahierten, vollkommen gültigen Session-Cookies werden anschließend an die Befehlsserver der Angreifer übertragen. Durch das Importieren dieser gestohlenen Cookies in einen eigenen Browser spiegelt der Angreifer die aktive Sitzung des Opfers exakt wider. Das Zielsystem bewertet diese Anfrage als legitime Fortsetzung der bestehenden Sitzung, wodurch jegliche MFA-Schranke wirkungslos umgangen wird.
Warum traditionelle Multi-Faktor-Authentifizierung bei Session-Hijacking versagt
Das fundamentale Versagen herkömmlicher MFA-Verfahren bei dieser Form des Angriffs liegt in der zeitlichen und logischen Trennung von Authentifizierung und Autorisierung begründet. Protokolle wie SAML 2.0, OpenID Connect oder OAuth 2.0 prüfen den zweiten Faktor ausschließlich im Moment der primären Anmeldung. Sobald das resultierende Sitzungstoken generiert und an den Client übermittelt wurde, gilt die Identität des Nutzers für die gesamte Lebensdauer des Tokens als bewiesen.
Wenn ein Angreifer dieses Token kopiert und von einem völlig anderen geografischen Standort oder einem nicht verwalteten Gerät präsentiert, kann der Server den Betrug anhand des Tokens selbst nicht erkennen. Herkömmliche Sicherheitsmechanismen wie der Abgleich der IP-Adresse oder geografische Plausibilitätsprüfungen greifen in der Praxis oft zu kurz. Professionelle Angreifer nutzen VPN-Dienste oder infizierte Proxysysteme im Wohnumfeld des Opfers (Residential Proxies), um dem Zielsystem eine identische Netzwerkumgebung vorzuspiegeln. Da das Token an sich keine physische Bindung an das spezifische Endgerät aufweist, auf dem es generiert wurde, fungiert es wie ein digitaler Generalschlüssel, der kopiert und universell eingesetzt werden kann.
Technische Gegenmaßnahmen und Protokollarchitekturen im direkten Vergleich
Um die Verwundbarkeit gegenüber dem Diebstahl von Sitzungsdaten zu eliminieren, muss die technologische Infrastruktur von statischen Token auf verifizierbare Besitznachweise umgestellt werden. Die folgende Übersicht dokumentiert die Sicherheitsmerkmale unterschiedlicher Token-Architekturen:
| Sicherheitskonzept | Funktionsprinzip | Schutzwirkung gegen Infostealer | Architektonische Implementierungshürde |
| Traditionelle Session-Cookies | Statische Zeichenkette im Browserspeicher; wird bei jedem HTTP-Request unverschlüsselt übertragen. | Absolut ungeschützt; einfaches Kopieren reicht für vollständige Kontenübernahme. | Keine; historischer Standard im gesamten Web. |
| Application-Bound Encryption | Lokale Verschlüsselung der Browserdaten gekoppelt an die spezifische Anwendungs-ID unter Windows. | Moderat; erschwert das Auslesen durch generische Skripte, schützt nicht vor hochentwickelter Malware. | Gering; wird von modernen Browsern wie Chrome automatisiert im Hintergrund ausgeführt. |
| Token Binding (HTTPS) | Kryptografische Verknüpfung des Tokens mit dem spezifischen TLS-Kanal des Endgeräts. | Maximal; das Token ist außerhalb der spezifischen TLS-Sitzung unbrauchbar. | Extrem hoch; erfordert lückenlose Unterstützung durch sämtliche Proxies, Firewalls und Webserver. |
| Demonstrating Proof-of-Possession (DPoP) | Client signiert jede Anfrage mit einem flüchtigen, asymmetrischen Schlüsselpaar auf Anwendungsebene. | Sehr hoch; Angreifer muss neben dem Token auch Zugriff auf den privaten Schlüssel erlangen. | Moderat; erfordert Anpassungen in den OAuth-Bibliotheken der Webanwendung und des Identitätsdienstes. |
Demonstrating Proof-of-Possession als kryptografischer Schutzschild
Als praxistaugliche und plattformunabhängige Lösung zur Abwehr von Session-Hijacking etabliert sich das Protokoll Demonstrating Proof-of-Possession, universell als DPoP bezeichnet und im Standard RFC 9449 definiert. DPoP bricht mit dem Prinzip der reinen Inhabertoken (Bearer Tokens). Anstatt ein Token zu generieren, das von jedem beliebigen Präsentator genutzt werden kann, zwingt DPoP den Client dazu, seine legitime Verfügungsgewalt über das Token bei jedem einzelnen API-Aufruf kryptografisch nachzuweisen.
Bei der Initialisierung einer DPoP-Sitzung generiert der Webbrowser des Nutzers ein flüchtiges, asymmetrisches Schlüsselpaar. Wenn die Anwendung ein Zugriffstoken vom Identitätsdienst anfordert, erstellt der Client ein lokales DPoP-Prüfzeichen (DPoP Proof). Dieses Prüfzeichen ist ein digital signiertes JSON Web Token, das spezifische Metadaten der aktuellen HTTP-Anfrage enthält, darunter die exakte HTTP-Methode, die Ziel-URI, einen Zeitstempel und eine eindeutige Zufallszahl (Nonce) zur Verhinderung von Replay-Angriffen.
Der Identitätsdienst überprüft diese Signatur und stellt ein Zugriffstoken aus, das den SHA-256-Fingerabdruck des öffentlichen Kundenschlüssels fest in seiner Datenstruktur integriert. Wenn die Anwendung dieses Token nun an eine geschützte Ressource übermittelt, muss sie zwingend einen neuen, aktuellen DPoP-Proof mitsenden. Der Zielserver validiert, ob der im Token eingebettete Fingerabdruck exakt mit dem öffentlichen Schlüssel übereinstimmt, mit dem die aktuelle Anfrage signiert wurde. Ein gestohlenes DPoP-Token ist für einen Angreifer nutzlos, da er ohne den dazugehörigen privaten Schlüssel, der isoliert im Arbeitsspeicher des Opfer-Browsers verbleibt, keine gültigen Anfrage-Signaturen erzeugen kann.
Token Binding und gerätegebundene Sitzungen in der Enterprise-Praxis
Ergänzend zu Protokollanpassungen auf Anwendungsebene wie DPoP müssen Unternehmen Architekturen für gerätegebundene Sitzungen (Device-Bound Sessions) implementieren. Da die flächendeckende Umsetzung des historischen Token Binding Standards auf TLS-Ebene an der mangelnden Unterstützung durch zwischengeschaltete Netzwerkinfrastrukturen wie Content Delivery Networks und Web Application Firewalls scheiterte, verlagert sich der Fokus auf hybride Ansätze. Ein konkretes Beispiel ist das Device Bound Session Credentials Framework, welches von führenden Browser-Herstellern vorangetrieben wird.
Dieses Framework verknüpft den Lebenszyklus einer Websitzung direkt mit den Hardware-Sicherheitschips des Endgeräts, wie dem Trusted Platform Module (TPM 2.0). Bei der Anmeldung wird ein kryptografischer Schlüssel generiert, dessen privater Teil das TPM physisch niemals verlassen kann. Der Browser signiert in regelmäßigen Abständen eine Herausforderung des Servers mit diesem Hardwareschlüssel. Versucht ein Infostealer, die Sitzung auf ein anderes Gerät zu übertragen, schlägt diese regelmäßige Hardware-Attestierung fehl, und der Identitätsdienst widerruft die Sitzung augenblicklich.
Für eine lückenlose Enterprise-Absicherung müssen CISOs diese kryptografischen Verfahren mit Continuous Access Evaluation, kurz CAE, kombinieren. Traditionelle Token weisen oft Gültigkeitsdauern von mehreren Stunden auf, in denen ein Angreifer trotz veränderter Risikolage agieren kann. CAE ermöglicht eine Echtzeit-Kommunikation zwischen dem Identitätsdienst und den genutzten Cloud-Anwendungen. Sobald ein anomales Verhalten erkannt wird, wie der plötzliche Wechsel des Endgeräts oder der Plattform, wird die Sitzung nicht erst nach Ablauf des Tokens, sondern im Millisekundenbereich global terminiert. Die konsequente Verknüpfung von Phishing-resistenter FIDO2-Authentifizierung beim Login und einer hardware- oder schlüsselgebundenen Absicherung der laufenden Sitzung über DPoP bildet das verlässliche Fundament, um die Identitäten von Unternehmen gegen die fortschreitende Professionalisierung der Infostealer-Kriminalität wirksam und dauerhaft zu schützen.
