Infostealer-Logs haben sich von einer Nischenware des Untergrunds zu einem operativen Sicherheitsproblem entwickelt. Für Sicherheitsteams ist der Fund einer kompromittierten Anmeldeinformation oft erst der Anfang – denn immer mehr Analysten beginnen ihren Arbeitstag mit einer Alarmmeldung: Die geschäftliche E-Mail-Adresse eines Mitarbeiters ist in einem frisch gesammelten Infostealer-Log aufgetaucht. Das Log enthält den Benutzernamen und das Passwort für eine unternehmenskritische SaaS-Anwendung, dazu Browser-Cookies – also lebende Sitzungen, die ausgenutzt werden können – sowie weitere gespeicherte Zugangsdaten. Ein privater Mitarbeiterrechner, Hunderte Kilometer vom Firmensitz entfernt, wurde mit Vidar infiziert. Was nun?
Das betroffene Passwort zurückzusetzen, scheint naheliegend. Doch das allein löst das Problem nicht. Hat der Stealer ein authentifiziertes Session-Cookie erbeutet, kann ein Angreifer unter Umständen direkt auf die Anwendung zugreifen – ohne Passwort und ohne zweite Authentifizierung (MFA). Hat der Mitarbeiter seine Unternehmenszugangsdaten auf dem Privatrecher wiederverwendet, ist das Endgerät, das die Offenlegung verursacht hat, möglicherweise gar nicht vom Unternehmen verwaltet. Und in einem einschlägigen Telegram-Kanal ist dieselbe Information für Initial Access Broker, Ransomware-Partner oder Gelegenheitsangreifer bereits verfügbar. Dies ist die operative Herausforderung, der Sicherheitsteams bei Infostealer-Logs zunehmend gegenüberstehen.
Rund 46 Prozent der Stealer-Logs mit Unternehmenszugangsdaten stammen Schätzungen zufolge von wahrscheinlich unverwalteten oder privaten Geräten. Die Zahl der Offenlegungen von Anmeldeinformationen und Sitzungen für wichtige Produktivitäts-SaaS und Cloud-Dienste steigt jährlich um etwa 29 Prozent. Die Frage ist für Verteidiger daher nicht mehr, ob sie Infostealer-Logs überwachen sollten. Die schwierigere Frage lautet: Wie trennt man ein unbedeutendes, altes Passwort von einer Identitätskompromittierung, die gerade in diesem Moment stattfindet?
Die Nadel unter Millionen Nadeln
Infostealer wie RedLine, Lumma, Vidar und andere Malware-Familien sind darauf ausgelegt, auf infizierten Systemen gespeicherte Informationen zu sammeln. Je nach Malware und Konfiguration können dies gespeicherte Browser-Passwörter, Cookies, Autofill-Daten, Kryptowährungs-Wallets, Systeminformationen, VPN-Konfigurationen und weitere Authentifizierungsartefakte sein. Diese werden zu einem Infostealer-Log zusammengefasst; eine einzige Infektion kann Hunderte oder Tausende von Datensätzen erzeugen. Multipliziert mit dem globalen Malware-Ökosystem entsteht für Verteidiger schnell ein Skalierungsproblem. Während sie alles verarbeiten und validieren müssen, genügt dem Angreifer ein einziges gültiges, wertvolles Zugangsdatenset. Es geht nicht darum, eine Nadel im Heuhaufen zu finden, sondern eine bestimmte Nadel unter Millionen von Nadeln in Millionen von Heuhaufen.
Während Stealer-Logs historisch über Untergrundforen und Marktplätze zirkulierten, erscheinen schätzungsweise 90 Prozent der Logs heute auf Telegram. Dort bieten öffentliche Kanäle Beispiele an, und private Abonnement-Kanäle ermöglichen Zugriff auf aktuellere Datensätze.
Ein Passwort ist nicht immer die größte Gefahr im Log
Bei der schieren Datenmenge aus zahlreichen Kanälen ist es schwer, das Risiko zu priorisieren. Wer für ein Großunternehmen arbeitet, hat Tausende Mitarbeiter. Beginnen zwei Alarme den Arbeitstag, stellt sich die Frage: Welcher Fall ist riskanter? Der erste Alarm könnte das alte Passwort eines Mitarbeiters für eine Verbraucherwebsite in einem sechs Monate alten Stealer-Log betreffen, der zweite Alarm hingegen stammt von gestern und enthält die Unternehmensidentität sowie eine authentifizierte Browser-Sitzung für den Identitätsanbieter der Organisation. Beide werden als Mitarbeiter-Zugangsdaten-Exposition gemeldet – doch sie sind grundverschieden.
Daher sollten Praktiker die Überwachung auf Assets konzentrieren, die Aussagen über die potenzielle Auswirkung erlauben: Unternehmensdomänen und Subdomänen, Identitätsanbieter, Session-Cookies, VPN- und RDP-Endpunkte sowie Cloud-Konsolen. Identitätsanbieter verdienen besondere Aufmerksamkeit, denn eine kompromittierte SSO-Identität (Microsoft Entra ID, Okta, Google Cloud Identity etc.) kann den Zugriff auf zahlreiche verbundene Anwendungen öffnen. Automatisierte Verifizierung und Schadensbegrenzung verstärken diesen Schutz zusätzlich.
Die Gefahr von Session-Cookies
Nach erfolgreicher Authentifizierung stellt eine Anwendung ein Session-Cookie aus, damit der Benutzer nicht bei jeder Anfrage erneut seine Identität nachweisen muss. Stiehlt die Malware dieses authentifizierte Cookie, kann ein Angreifer es unter Umständen wiederverwenden. Er muss sich dann nicht mehr anmelden – gestohlene Zugangsdaten allein erfordern einen Login-Vorgang, den Verteidiger erkennen oder blockieren könnten. Ein gültiges Session-Cookie umgeht diesen Schritt vollständig und damit auch die Multi-Faktor-Authentifizierung.
Die ersten 60 Sekunden
Unmittelbar nach der Entdeckung potenziell relevanter Stealer-Daten empfiehlt sich eine erste Bewertung, gefolgt von Risikoeinstufung und Validierung. Ziel ist nicht, die gesamte Untersuchung in den ersten Minuten durchzuführen, sondern zu bestimmen, wie schnell die Organisation reagieren muss. Die erste Frage lautet: Was genau wurde gestohlen? Ein Analyst sollte ermitteln, wann die Infektion stattfand, welches System das Log erzeugt hat, wie viele Unternehmenszugangsdaten enthalten sind und ob authentifizierte Sitzungen erfasst wurden. Danach kommt der geschäftliche Kontext: Eine Zugangsdaten für testserver.firma.de sollte nicht dieselbe Priorität erhalten wie eine für finanz.firma.de. Ebenso sollte die offengelegte Identität eines Marketing-Praktikanten nicht automatisch genauso behandelt werden wie die eines Administrators mit Zugriff auf Identitätsanbieter, Cloud-Konsole und Produktionsinfrastruktur.
Ein Rahmenwerk stuft daher Unternehmensidentitätsdaten in Kombination mit Session-Cookies als kritisch ein (Reaktionszeit unter einer Stunde). VPN/RDP-Zugriff in Kombination mit mehreren Unternehmenszugangsdaten wird als hoch eingestuft, aufgrund des Potenzials für laterale Bewegung.
Von der Offenlegung zur Untersuchung
Angenommen, das Log des hypothetischen Mitarbeiters enthält eine Entra-ID-Zugangsdaten, SaaS-Passwörter und Browser-Cookies – dann stellt sich die Frage, ob jemand diese bereits genutzt hat. Verteidiger können die offengelegte Identität mit Authentifizierungstelemetrie abgleichen: erfolgreiche und fehlgeschlagene Anmeldungen, unerwartete geografische Orte, ungewöhnliche Geräte, unbekannte IP-Adressen sowie Zugriff auf Ressourcen außerhalb des normalen Benutzerverhaltens. Zudem muss geprüft werden, ob die gestohlenen Informationen noch nutzbar sind: Wurde das Passwort nach der Infektion geändert? Ist die Sitzung abgelaufen? Ist das Konto noch aktiv?
Der empfohlene Untersuchungsablauf erweitert die Analyse um Browser-Fingerprint-Informationen, das gesamte Inventar gespeicherter Zugangsdaten, Informationen über das infizierte System sowie weitere Artefakte wie VPN-Konfigurationen oder SSH-Schlüssel. Wer ist der Mitarbeiter? Worauf hat seine Identität Zugriff? War der infizierte Rechner unternehmenseigen oder privat? Handelt es sich um eine einzelne Infektion oder um Hinweise auf eine breitere Kampagne? Anschließend sollten Authentifizierungslogs der Systeme durchsucht werden, die für diese Identität zugänglich sind – zuerst die sensibelsten Ressourcen. Verteidiger müssen gezielt nach Verhaltensmustern suchen, die anzeigen, dass aus der Offenlegung eine Kontoübernahme geworden ist: Authentifizierung von unerwarteten Standorten, Zugriff inkonsistent mit der Benutzerrolle, ungewöhnliche Downloads, Passwortzurücksetzungen und die Registrierung neuer MFA-Geräte. So wird ein Stealer-Log zum Frühwarnsystem für Identitätskompromittierung.
Stealer-Logs als Identitätsproblem behandeln
Sobald eine risikoreiche Offenlegung bestätigt ist, zählt Geschwindigkeit. Verteidiger sollten kompromittierte Sitzungen ungültig machen, betroffene Zugangsdaten zurücksetzen und die Überwachung der Identität verstärken. Über einzelne Vorfälle hinaus sollten Organisationen wiederkehrende Offenlegungen, betroffene Anwendungen und die Frage nachverfolgen, ob gestohlene Zugangsdaten zu Zugriffsversuchen geführt haben. Letztlich ist die Überwachung von Infostealer-Logs zu einer unverzichtbaren Schicht der Identitätssicherheit geworden. Sie befähigt Unternehmen, offengelegte Zugangsdaten und Sitzungen zu identifizieren, den damit verbundenen Zugriff zu verstehen, festzustellen, ob diese noch ausnutzbar sind, und eine potenzielle Kontoübernahme zu unterbinden, bevor sie zu einer umfassenderen Kompromittierung führt.
