Infostealer-Logs haben sich von einer Nischenware des Untergrunds zu einem operativen Sicherheitsproblem entwickelt. F\u00fcr Sicherheitsteams ist der Fund einer kompromittierten Anmeldeinformation oft erst der Anfang \u2013 denn immer mehr Analysten beginnen ihren Arbeitstag mit einer Alarmmeldung: Die gesch\u00e4ftliche E-Mail-Adresse eines Mitarbeiters ist in einem frisch gesammelten Infostealer-Log aufgetaucht. Das Log enth\u00e4lt den Benutzernamen und das Passwort f\u00fcr eine unternehmenskritische SaaS-Anwendung, dazu Browser-Cookies \u2013 also lebende Sitzungen, die ausgenutzt werden k\u00f6nnen \u2013 sowie weitere gespeicherte Zugangsdaten. Ein privater Mitarbeiterrechner, Hunderte Kilometer vom Firmensitz entfernt, wurde mit Vidar infiziert. Was nun?<\/p>\n
Das betroffene Passwort zur\u00fcckzusetzen, scheint naheliegend. Doch das allein l\u00f6st das Problem nicht. Hat der Stealer ein authentifiziertes Session-Cookie erbeutet, kann ein Angreifer unter Umst\u00e4nden direkt auf die Anwendung zugreifen \u2013 ohne Passwort und ohne zweite Authentifizierung (MFA). Hat der Mitarbeiter seine Unternehmenszugangsdaten auf dem Privatrecher wiederverwendet, ist das Endger\u00e4t, das die Offenlegung verursacht hat, m\u00f6glicherweise gar nicht vom Unternehmen verwaltet. Und in einem einschl\u00e4gigen Telegram-Kanal ist dieselbe Information f\u00fcr Initial Access Broker, Ransomware-Partner oder Gelegenheitsangreifer bereits verf\u00fcgbar. Dies ist die operative Herausforderung, der Sicherheitsteams bei Infostealer-Logs zunehmend gegen\u00fcberstehen.<\/p>\n
Rund 46 Prozent der Stealer-Logs mit Unternehmenszugangsdaten stammen Sch\u00e4tzungen zufolge von wahrscheinlich unverwalteten oder privaten Ger\u00e4ten. Die Zahl der Offenlegungen von Anmeldeinformationen und Sitzungen f\u00fcr wichtige Produktivit\u00e4ts-SaaS und Cloud-Dienste steigt j\u00e4hrlich um etwa 29 Prozent. Die Frage ist f\u00fcr Verteidiger daher nicht mehr, ob sie Infostealer-Logs \u00fcberwachen sollten. Die schwierigere Frage lautet: Wie trennt man ein unbedeutendes, altes Passwort von einer Identit\u00e4tskompromittierung, die gerade in diesem Moment stattfindet?<\/p>\n
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\u00f6nnen dies gespeicherte Browser-Passw\u00f6rter, Cookies, Autofill-Daten, Kryptow\u00e4hrungs-Wallets, Systeminformationen, VPN-Konfigurationen und weitere Authentifizierungsartefakte sein. Diese werden zu einem Infostealer-Log zusammengefasst; eine einzige Infektion kann Hunderte oder Tausende von Datens\u00e4tzen erzeugen. Multipliziert mit dem globalen Malware-\u00d6kosystem entsteht f\u00fcr Verteidiger schnell ein Skalierungsproblem. W\u00e4hrend sie alles verarbeiten und validieren m\u00fcssen, gen\u00fcgt dem Angreifer ein einziges g\u00fcltiges, wertvolles Zugangsdatenset. Es geht nicht darum, eine Nadel im Heuhaufen zu finden, sondern eine bestimmte Nadel unter Millionen von Nadeln in Millionen von Heuhaufen.<\/p>\n
W\u00e4hrend Stealer-Logs historisch \u00fcber Untergrundforen und Marktpl\u00e4tze zirkulierten, erscheinen sch\u00e4tzungsweise 90 Prozent der Logs heute auf Telegram. Dort bieten \u00f6ffentliche Kan\u00e4le Beispiele an, und private Abonnement-Kan\u00e4le erm\u00f6glichen Zugriff auf aktuellere Datens\u00e4tze.<\/p>\n
Bei der schieren Datenmenge aus zahlreichen Kan\u00e4len ist es schwer, das Risiko zu priorisieren. Wer f\u00fcr ein Gro\u00dfunternehmen arbeitet, hat Tausende Mitarbeiter. Beginnen zwei Alarme den Arbeitstag, stellt sich die Frage: Welcher Fall ist riskanter? Der erste Alarm k\u00f6nnte das alte Passwort eines Mitarbeiters f\u00fcr eine Verbraucherwebsite in einem sechs Monate alten Stealer-Log betreffen, der zweite Alarm hingegen stammt von gestern und enth\u00e4lt die Unternehmensidentit\u00e4t sowie eine authentifizierte Browser-Sitzung f\u00fcr den Identit\u00e4tsanbieter der Organisation. Beide werden als Mitarbeiter-Zugangsdaten-Exposition gemeldet \u2013 doch sie sind grundverschieden.<\/p>\n
Daher sollten Praktiker die \u00dcberwachung auf Assets konzentrieren, die Aussagen \u00fcber die potenzielle Auswirkung erlauben: Unternehmensdom\u00e4nen und Subdom\u00e4nen, Identit\u00e4tsanbieter, Session-Cookies, VPN- und RDP-Endpunkte sowie Cloud-Konsolen. Identit\u00e4tsanbieter verdienen besondere Aufmerksamkeit, denn eine kompromittierte SSO-Identit\u00e4t (Microsoft Entra ID, Okta, Google Cloud Identity etc.) kann den Zugriff auf zahlreiche verbundene Anwendungen \u00f6ffnen. Automatisierte Verifizierung und Schadensbegrenzung verst\u00e4rken diesen Schutz zus\u00e4tzlich.<\/p>\n
Nach erfolgreicher Authentifizierung stellt eine Anwendung ein Session-Cookie aus, damit der Benutzer nicht bei jeder Anfrage erneut seine Identit\u00e4t nachweisen muss. Stiehlt die Malware dieses authentifizierte Cookie, kann ein Angreifer es unter Umst\u00e4nden wiederverwenden. Er muss sich dann nicht mehr anmelden \u2013 gestohlene Zugangsdaten allein erfordern einen Login-Vorgang, den Verteidiger erkennen oder blockieren k\u00f6nnten. Ein g\u00fcltiges Session-Cookie umgeht diesen Schritt vollst\u00e4ndig und damit auch die Multi-Faktor-Authentifizierung.<\/p>\n
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\u00fchren, 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\u00e4ftliche Kontext: Eine Zugangsdaten f\u00fcr testserver.firma.de sollte nicht dieselbe Priorit\u00e4t erhalten wie eine f\u00fcr finanz.firma.de. Ebenso sollte die offengelegte Identit\u00e4t eines Marketing-Praktikanten nicht automatisch genauso behandelt werden wie die eines Administrators mit Zugriff auf Identit\u00e4tsanbieter, Cloud-Konsole und Produktionsinfrastruktur.<\/p>\n
Ein Rahmenwerk stuft daher Unternehmensidentit\u00e4tsdaten 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\u00fcr laterale Bewegung.<\/p>\n
Angenommen, das Log des hypothetischen Mitarbeiters enth\u00e4lt eine Entra-ID-Zugangsdaten, SaaS-Passw\u00f6rter und Browser-Cookies \u2013 dann stellt sich die Frage, ob jemand diese bereits genutzt hat. Verteidiger k\u00f6nnen die offengelegte Identit\u00e4t mit Authentifizierungstelemetrie abgleichen: erfolgreiche und fehlgeschlagene Anmeldungen, unerwartete geografische Orte, ungew\u00f6hnliche Ger\u00e4te, unbekannte IP-Adressen sowie Zugriff auf Ressourcen au\u00dferhalb des normalen Benutzerverhaltens. Zudem muss gepr\u00fcft werden, ob die gestohlenen Informationen noch nutzbar sind: Wurde das Passwort nach der Infektion ge\u00e4ndert? Ist die Sitzung abgelaufen? Ist das Konto noch aktiv?<\/p>\n
Der empfohlene Untersuchungsablauf erweitert die Analyse um Browser-Fingerprint-Informationen, das gesamte Inventar gespeicherter Zugangsdaten, Informationen \u00fcber das infizierte System sowie weitere Artefakte wie VPN-Konfigurationen oder SSH-Schl\u00fcssel. Wer ist der Mitarbeiter? Worauf hat seine Identit\u00e4t Zugriff? War der infizierte Rechner unternehmenseigen oder privat? Handelt es sich um eine einzelne Infektion oder um Hinweise auf eine breitere Kampagne? Anschlie\u00dfend sollten Authentifizierungslogs der Systeme durchsucht werden, die f\u00fcr diese Identit\u00e4t zug\u00e4nglich sind \u2013 zuerst die sensibelsten Ressourcen. Verteidiger m\u00fcssen gezielt nach Verhaltensmustern suchen, die anzeigen, dass aus der Offenlegung eine Konto\u00fcbernahme geworden ist: Authentifizierung von unerwarteten Standorten, Zugriff inkonsistent mit der Benutzerrolle, ungew\u00f6hnliche Downloads, Passwortzur\u00fccksetzungen und die Registrierung neuer MFA-Ger\u00e4te. So wird ein Stealer-Log zum Fr\u00fchwarnsystem f\u00fcr Identit\u00e4tskompromittierung.<\/p>\n
Sobald eine risikoreiche Offenlegung best\u00e4tigt ist, z\u00e4hlt Geschwindigkeit. Verteidiger sollten kompromittierte Sitzungen ung\u00fcltig machen, betroffene Zugangsdaten zur\u00fccksetzen und die \u00dcberwachung der Identit\u00e4t verst\u00e4rken. \u00dcber einzelne Vorf\u00e4lle hinaus sollten Organisationen wiederkehrende Offenlegungen, betroffene Anwendungen und die Frage nachverfolgen, ob gestohlene Zugangsdaten zu Zugriffsversuchen gef\u00fchrt haben. Letztlich ist die \u00dcberwachung von Infostealer-Logs zu einer unverzichtbaren Schicht der Identit\u00e4tssicherheit geworden. Sie bef\u00e4higt Unternehmen, offengelegte Zugangsdaten und Sitzungen zu identifizieren, den damit verbundenen Zugriff zu verstehen, festzustellen, ob diese noch ausnutzbar sind, und eine potenzielle Konto\u00fcbernahme zu unterbinden, bevor sie zu einer umfassenderen Kompromittierung f\u00fchrt.<\/p>\n","protected":false},"excerpt":{"rendered":"
Infostealer-Logs haben sich von einer Nischenware des Untergrunds zu einem operativen Sicherheitsproblem entwickelt. F\u00fcr Sicherheitsteams ist der Fund einer kompromittierten Anmeldeinformation oft erst der Anfang \u2013 denn immer mehr Analysten beginnen ihren Arbeitstag mit einer Alarmmeldung: Die gesch\u00e4ftliche E-Mail-Adresse eines Mitarbeiters ist in einem frisch gesammelten Infostealer-Log aufgetaucht. Das Log enth\u00e4lt den Benutzernamen und das […]<\/p>\n","protected":false},"author":5,"featured_media":54834,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51057.png","fifu_image_alt":"Mitarbeiter-Passwort in Infostealer-Log erfordert sofortiges Handeln","footnotes":""},"categories":[6671],"tags":[],"class_list":["post-51057","post","type-post","status-publish","format-standard","has-post-thumbnail","category-scherheit"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51057.png","fifu_image_alt":"Mitarbeiter-Passwort in Infostealer-Log erfordert sofortiges Handeln","_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51057","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=51057"}],"version-history":[{"count":1,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51057\/revisions"}],"predecessor-version":[{"id":51062,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51057\/revisions\/51062"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media\/54834"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=51057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=51057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=51057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}