Credentials from Web Browsers erkennen: Browser-Passwortspeicher unter Windows, Linux und macOS

Credentials from Web Browsers erkennen heißt, einen der ergiebigsten Zugangsdaten-Speicher überhaupt zu überwachen: Im Browser liegen die Passwörter zu Cloud-Konsolen, SaaS-Anwendungen und internen Portalen, dazu die Session-Cookies, mit denen sich eine laufende Anmeldung samt bestandener Mehr-Faktor-Prüfung übernehmen lässt. Der Beitrag Infostealer erkennen behandelt die Windows-Seite aus der Perspektive der Schadsoftware-Familien, mit SACL, Event 4663 und DPAPI-Masterkeys. Dieser Beitrag setzt eine Ebene tiefer und breiter an: Er erklärt, wie die Browser-Speicher auf Windows, Linux und macOS aufgebaut und geschützt sind, warum ein Dateizugriff noch kein Diebstahl ist, welche Telemetrie jede Plattform liefert und wie sich der echte Dump vom Browser-Import oder vom Backup unterscheidet.

Wo Browser Zugangsdaten speichern - und womit sie geschützt sind

Drei Browser-Familien, drei Plattformen, und jede Kombination schützt die Daten anders. Das ist keine Fleißarbeit, sondern die Grundlage jeder Bewertung: Wer weiß, welchen Schlüssel ein Angreifer auf dieser Plattform braucht, weiß, welchen zweiten Zugriff er suchen muss.

• Chromium-Browser (Chrome, Edge, Brave, Opera, Vivaldi). Passwörter liegen in der SQLite-Datei Login Data im Profilordner (unter User Data\Default beziehungsweise dem jeweiligen Profil), Autofill in Web Data, Cookies in Network/Cookies. Die Werte sind verschlüsselt, der Schlüssel steht in Local State. Unter Windows ist dieser Schlüssel mit DPAPI an den Benutzer gebunden; aktuelle Chrome- und Edge-Versionen binden ihn zusätzlich per App-Bound Encryption an den Browser selbst, sodass ein Prozess im Benutzerkontext ihn nicht mehr einfach per DPAPI entschlüsseln kann - er braucht erhöhte Rechte, einen Umweg über den Browser oder die DevTools-Schnittstelle. Unter macOS liegt der Schlüssel als "Chrome Safe Storage" (bei Edge "Microsoft Edge Safe Storage") in der Keychain; der Zugriff durch einen fremden Prozess löst einen Keychain-Dialog aus oder läuft über das security-Werkzeug. Unter Linux liegt er im Schlüsselbund (GNOME Keyring oder KWallet über libsecret) - oder, wenn kein Schlüsselbund läuft, schützt ein fester, öffentlich bekannter Standardschlüssel die Daten nur noch formal.
• Firefox (und Thunderbird). Passwörter stehen in logins.json, der Schlüssel in der NSS-Datenbank key4.db, beides im Profilordner (~/.mozilla/firefox/, %APPDATA%\Mozilla\Firefox\Profiles\, ~/Library/Application Support/Firefox/Profiles/). Ohne gesetztes Hauptpasswort lassen sich beide Dateien auf jeder Plattform offline entschlüsseln - es gibt keine Bindung an Benutzer oder Gerät. Cookies liegen in cookies.sqlite.
• Safari. Safari speichert Passwörter nicht in einer eigenen Datenbank, sondern in der Keychain beziehungsweise iCloud-Schlüsselbund. Der Diebstahl ist deshalb ein Keychain-Zugriff und im Beitrag Keychain-Zugriff erkennen behandelt. Safaris Cookies und Verlauf unter ~/Library/Safari und im Safari-Container (~/Library/Containers/com.apple.Safari/) sind durch TCC geschützt - ein fremder Prozess braucht dafür Vollzugriff auf die Festplatte.

Was der Angreifer tut

Der Weg ist auf allen Plattformen derselbe, nur der Schlüssel unterscheidet sich. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Datenbank kopieren. Weil der laufende Browser seine SQLite-Dateien sperrt, kopiert der Angreifer Login Data oder logins.json an einen Arbeitsort - ein Temp-Verzeichnis, einen Download-Ordner - und liest die Kopie. Unter Windows hilft dabei esentutl, unter Linux und macOS reichen cp und sqlite3.
• Schlüssel beschaffen. Unter Windows den Schlüssel aus Local State per DPAPI entschlüsseln, bei App-Bound Encryption zusätzlich den Browser-Umweg nehmen; unter macOS "Chrome Safe Storage" aus der Keychain holen (security find-generic-password -wa Chrome); unter Linux den Schlüsselbund abfragen (secret-tool) oder den Standardschlüssel nutzen; bei Firefox key4.db mitnehmen.
• Entschlüsseln und verpacken. Werkzeuge wie LaZagne, HackBrowserData oder SharpChrome und jeder Infostealer (RedLine, Lumma, Vidar, Atomic Stealer unter macOS) automatisieren diese Schritte und schreiben das Ergebnis als Klartext in ein Archiv.
• Den laufenden Browser abfragen. Statt die Datenbank zu entschlüsseln, startet der Angreifer den Browser mit Remote-Debugging-Schnittstelle oder hängt sich an eine laufende Instanz und fragt Cookies und gespeicherte Anmeldedaten über das DevTools-Protokoll ab. Das umgeht die App-Bound Encryption, weil der Browser selbst entschlüsselt - und ist der Grund, warum Chrome den Zugriff auf das Standardprofil per Remote-Debugging inzwischen einschränkt.

Zugriff ist nicht Diebstahl: die Beweiskette

Ein Treffer auf Login Data ist zunächst nur ein Dateizugriff, und davon gibt es viele legitime: Der Browser selbst liest und schreibt ständig, Edge importiert beim ersten Start die Chrome-Daten und liest dafür genau diese Datei, Backup- und Migrationswerkzeuge sichern ganze Profile, Virenscanner lesen jede Datei, Passwortmanager bieten Browser-Import an, und das Synchronisationsprofil eines zweiten Browsers greift ebenfalls zu. Credential Dumping ist erst die Kette: Ein fremder Prozess liest oder kopiert die Datenbank, derselbe Prozess beschafft sich den Schlüssel (Local State plus DPAPI, Keychain-Eintrag, Schlüsselbund, key4.db), entschlüsselt und schreibt das Ergebnis weg oder lädt es hoch. Jedes Glied allein ist mehrdeutig; zusammen in kurzer Folge sind sie eindeutig. Die Regeln unten liefern die Glieder - die Bewertung muss sie zusammensetzen.

Welche Telemetrie die Technik zeigt

• Windows - Prozess. Sysmon Event 1 oder Event 4688 mit Befehlszeilenprotokollierung zeigen das Kopieren per Kommandozeile und den Browserstart mit Remote-Debugging-Schalter. Sysmon Event 10 (ProcessAccess) zeigt einen Prozess, der sich Zugriff auf chrome.exe oder msedge.exe verschafft - der Weg um die App-Bound Encryption herum.
• Windows - Datei. Sysmon Event 11 zeigt die Kopie der Datenbank am Arbeitsort - nicht aber das Lesen des Originals, denn Sysmon hat kein Dateilese-Ereignis. Den lesenden Zugriff liefert nur Event 4663 mit aktivierter Überwachung des Objektzugriffs (Dateisystem) und einer SACL auf den Profildateien, oder eine EDR mit Dateizugriffs-Telemetrie. Die DPAPI-Entschlüsselung des Browser-Schlüssels erzeugt kein verwertbares Standardereignis: Die DPAPI-Überwachung (4692 bis 4695) greift nur für eigens als auditierbar markierte Daten, und der Browser-Schlüssel gehört nicht dazu. Diese Windows-Seite inklusive SACL und Masterkey-Zugriff behandelt Infostealer erkennen im Detail.
• Linux. auditd mit einem Datei-Watch auf das Profilverzeichnis zeigt jeden lesenden Zugriff samt Prozess (exe) und Konto - etwa -w /home/user/.config/google-chrome/Default -p r -k browsercreds; weil der Dateiname "Login Data" ein Leerzeichen enthält und Regeldateien das nicht abbilden, überwacht man das Verzeichnis und filtert im SIEM auf exe ungleich Browser. Das ist laut, weil der Browser ständig liest, aber präzise. Der execve-Datensatz und Sysmon for Linux Event 1 zeigen die Kommandozeile (sqlite3, cp, python, secret-tool), Event 11 die Kopie an einem neuen Ort. Der Zugriff auf den Schlüsselbund läuft über D-Bus und ist nur über den aufrufenden Prozess sichtbar, nicht als eigenes Ereignis. Die Grundlagen stehen unter Linux-Sicherheitsmonitoring.
• macOS. Das Endpoint Security Framework liefert Prozessereignisse mit Argumenten (der cp-, sqlite3- oder python-Aufruf) und Dateiöffnungen (open-Ereignisse) auf die Profildateien - letztere nur, wenn die EDR sie abonniert und nach Pfad filtert; eslogger kann das im Lab, für den Dauerbetrieb ist das Volumen hoch. Der Schlüsselzugriff ist der beste Anker: security find-generic-password auf "Chrome Safe Storage" ist ein Prozessereignis, das der Beitrag Keychain-Zugriff erkennen mit seiner zweiten Regel fängt; greift ein kompilierter Stealer über die Keychain-Schnittstelle zu, bleibt der Keychain-Dialog beziehungsweise die EDR-Sicht. Safari-Daten sind TCC-geschützt, ein Zugriff setzt also Vollzugriff auf die Festplatte voraus - was selbst ein Signal ist. Die Grundlagen stehen unter macOS-Sicherheitsmonitoring.
• EDR auf allen Plattformen. Eine EDR mit Dateizugriffs-Telemetrie sieht den fremden Lesezugriff ohne SACL und ohne auditd, und sie sieht den kompilierten Stealer, der keine Kommandozeile hinterlässt. Welche Dateizugriffe sie protokolliert und ob sie Browserprofile besonders behandelt, ist produktabhängig - vor dem Vertrauen auf diese Spur prüfen.

Das Muster

Das stärkste Einzelsignal ist eine Datei mit dem Namen einer Browser-Credential-Datenbank, die außerhalb jedes Browserprofils neu entsteht - die Kopie am Arbeitsort. Das zweite ist ein Prozess, der nicht der Browser ist und in kurzer Folge die Datenbank und den Schlüssel anfasst: Login Data und Local State, logins.json und key4.db, oder die Datenbank plus der security-Aufruf auf "Chrome Safe Storage". Das dritte ist der Browser selbst in ungewohnter Rolle: gestartet mit Remote-Debugging-Schalter aus einer Shell oder einem Skript statt aus einer Entwicklungsumgebung, oft mit einem fremden Benutzerprofil-Pfad. Dazu kommt auf jeder Plattform die Folge: ein Archiv im Temp-Verzeichnis und eine ausgehende Verbindung des fremden Prozesses. Legitimer Zugriff hat einen bekannten Urheber (Browser, Edge-Import, Backup-Agent, Virenscanner) und keinen Schlüsselzugriff durch denselben fremden Prozess - genau an dieser Unterscheidung hängt die Bewertung.

Vier Sigma-Regeln

Die Regeln sind mit sigma-cli validiert und bewusst als Zugriffs- und Randindikatoren beschrieben: Keine erkennt die Entschlüsselung selbst, jede liefert ein Glied der Beweiskette. Die erste fängt die Kopie der Datenbank außerhalb des Profils unter Windows, die zweite den Browserstart mit Remote-Debugging, die dritte und vierte den Kommandozeilen-Zugriff unter Linux und macOS. Die Windows-Regeln ergänzen die SACL-basierten Regeln aus Infostealer erkennen und wiederholen sie nicht. sigma-cli-validiert heißt dabei: syntaktisch und gegen das verwendete ATT&CK-Dataset geprüft, nicht produktiv getestet. Image, CommandLine und TargetFilename sind die portable Sigma-Abstraktion - unter Windows liefern Sysmon und Event 4688 sie direkt, unter Linux muss der Mapper sie aus den auditd-Feldern exe, a0 bis aN und den PATH-Datensätzen aufbauen (Sysmon for Linux liefert sie direkt), unter macOS hängt die Belegung von EDR, ESF-Pipeline und SIEM-Mapping ab. Die Übersetzung ins SIEM steht unter Sigma-Regeln; weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Credential Access.

1. Browser-Credential-Datenbank außerhalb des Profils angelegt (Windows, T1555.003). Die Kopie am Arbeitsort, auf level: high - der Browser und der Browser-Import schreiben nur ins Profil und sind ausgefiltert.

title: Browser-Credential-Datenbank ausserhalb des Browserprofils angelegt
id: d33a41db-4e8b-4a9c-943b-a1ef225112cf
status: experimental
description: |
  Erkennt das Anlegen einer Datei mit dem Namen einer Browser-Credential-Datenbank
  (Login Data, Web Data, logins.json, key4.db, Network/Cookies) ausserhalb eines
  Browser-Profilverzeichnisses, etwa in Temp-, Download- oder Benutzerordnern.
  Infostealer und Dumping-Werkzeuge kopieren die Datenbank zuerst an einen
  Arbeitsort, weil der Browser die Originaldatei sperrt, und entschluesseln sie dort
  (Credentials from Web Browsers). Der Browser selbst und Browser-Importe schreiben
  nur in Profilverzeichnisse und werden ausgefiltert. Die Kopie allein beweist noch
  keinen Diebstahl - erst zusammen mit dem Schluessel (Local State, DPAPI) und der
  Entschluesselung wird daraus Credential Dumping.
references:
  - https://attack.mitre.org/techniques/T1555/003/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.credential-access
  - attack.t1555.003
logsource:
  product: windows
  category: file_event
detection:
  sel_name:
    TargetFilename|endswith:
      - '\Login Data'
      - '\Login Data For Account'
      - '\Web Data'
      - '\logins.json'
      - '\key4.db'
      - '\Network\Cookies'
  filter_profile:
    TargetFilename|contains:
      - '\User Data\'
      - '\Mozilla\Firefox\Profiles\'
      - '\Thunderbird\Profiles\'
      - '\Opera Software\'
  filter_browser:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
      - '\opera.exe'
      - '\vivaldi.exe'
  condition: sel_name and not filter_profile and not filter_browser
falsepositives:
  - Backup- und Migrationswerkzeuge (USMT, Sicherungsagenten), die Benutzerprofile komplett an einen anderen Ort kopieren - bekannte Prozesse und Zielpfade als Baseline ausnehmen
  - Forensik- und Sammelwerkzeuge des eigenen Teams
level: high

2. Browser mit Remote-Debugging-Schnittstelle gestartet (Windows, T1555.003/T1539). Der Weg um die App-Bound Encryption herum, auf level: medium, weil Test-Automatisierung denselben Schalter nutzt.

title: Browser mit Remote-Debugging-Schnittstelle gestartet
id: 45347506-071b-4630-ac3e-37a080cc482b
status: experimental
description: |
  Erkennt den Start eines Chromium-basierten Browsers mit aktivierter
  Remote-Debugging-Schnittstelle (--remote-debugging-port oder
  --remote-debugging-pipe). Ueber das DevTools-Protokoll lassen sich Cookies und
  gespeicherte Anmeldedaten aus dem laufenden Browser abfragen, ohne die Datenbank
  selbst zu entschluesseln - ein Weg, der auch die App-Bound Encryption aktueller
  Chrome-Versionen umgeht. Entwickler und Test-Automatisierung (Selenium, Puppeteer,
  Playwright) nutzen denselben Schalter, deshalb traegt der Treffer erst mit dem
  Elternprozess und einem ungewoehnlichen Benutzerprofil Gewicht.
references:
  - https://attack.mitre.org/techniques/T1555/003/
  - https://attack.mitre.org/techniques/T1539/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.credential-access
  - attack.t1555.003
  - attack.t1539
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\brave.exe'
      - '\opera.exe'
      - '\vivaldi.exe'
  sel_cmd:
    CommandLine|contains:
      - '--remote-debugging-port'
      - '--remote-debugging-pipe'
  condition: sel_img and sel_cmd
falsepositives:
  - Entwickler-Arbeitsplaetze und Test-Automatisierung mit Selenium, Puppeteer oder Playwright - bekannte Hosts, Konten und Elternprozesse als Baseline ausnehmen
level: medium

3. Zugriff auf Browser-Credential-Speicher per Kommandozeile (Linux, T1555.003). Der Skript-Weg inklusive secret-tool für den Schlüsselbund, auf level: medium; kompilierte Stealer sieht die Regel nicht.

title: Zugriff auf Browser-Credential-Speicher per Kommandozeile (Linux)
id: c36bb547-771f-44ef-a5f1-21cb0e8c01f7
status: experimental
description: |
  Erkennt einen Prozess, der nicht der Browser ist und in seiner Kommandozeile eine
  Browser-Credential-Datenbank (Login Data, logins.json, key4.db, cookies.sqlite)
  oder den Chromium-Schluessel im Schluesselbund (secret-tool mit chrome/chromium)
  anspricht. Typisch fuer Skripte und Werkzeuge, die gespeicherte Browser-Passwoerter
  unter Linux auslesen (Credentials from Web Browsers). Die Regel sieht nur den
  Kommandozeilen-Weg; kompilierte Stealer, die die Dateien direkt oeffnen,
  erscheinen hier nicht - dafuer braucht es auditd-Dateiwatches oder eine EDR mit
  Dateizugriffs-Telemetrie. Ein Treffer ist ein Zugriffsindikator, kein Beweis fuer
  eine erfolgreiche Entschluesselung.
references:
  - https://attack.mitre.org/techniques/T1555/003/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.credential-access
  - attack.t1555.003
logsource:
  product: linux
  category: process_creation
detection:
  sel_files:
    CommandLine|contains:
      - 'Login Data'
      - 'logins.json'
      - 'key4.db'
      - 'cookies.sqlite'
  sel_keyring:
    Image|endswith: '/secret-tool'
    CommandLine|contains:
      - 'chrome'
      - 'chromium'
  filter_browser:
    Image|endswith:
      - '/chrome'
      - '/chromium'
      - '/chromium-browser'
      - '/firefox'
      - '/firefox-bin'
      - '/brave'
      - '/msedge'
  condition: (sel_files or sel_keyring) and not filter_browser
falsepositives:
  - Backup-Skripte und Profil-Migrationen, die Browserprofile kopieren - bekannte Skripte und Konten als Baseline ausnehmen
  - Administratoren und Forensiker, die Browserprofile untersuchen
level: medium

4. Zugriff auf Browser-Credential-Speicher per Kommandozeile (macOS, T1555.003). Das macOS-Gegenstück, auf level: medium; der Schlüsselzugriff über security ist in der Keychain-Regel abgedeckt.

title: Zugriff auf Browser-Credential-Speicher per Kommandozeile (macOS)
id: d7bc943e-cf07-4b9b-9732-55f74313c730
status: experimental
description: |
  Erkennt einen Prozess, der nicht der Browser ist und in seiner Kommandozeile eine
  Browser-Credential-Datenbank (Login Data, logins.json, key4.db, cookies.sqlite)
  anspricht. Typisch fuer Skripte und Werkzeuge, die gespeicherte Browser-Passwoerter
  unter macOS kopieren oder auslesen (Credentials from Web Browsers). Den zugehoerigen
  Schluessel (Chrome Safe Storage) holen sie aus der Keychain - dieser Schritt wird
  ueber den security-Aufruf erkannt, nicht ueber diese Regel. Die Regel sieht nur den
  Kommandozeilen-Weg; kompilierte Stealer, die die Dateien direkt oeffnen, erscheinen
  hier nicht und brauchen eine EDR mit ESF-Dateizugriffs-Telemetrie. Ein Treffer ist
  ein Zugriffsindikator, kein Beweis fuer eine erfolgreiche Entschluesselung.
references:
  - https://attack.mitre.org/techniques/T1555/003/
author: blue-team.net
date: 2026-10-09
tags:
  - attack.credential-access
  - attack.t1555.003
logsource:
  product: macos
  category: process_creation
detection:
  sel_files:
    CommandLine|contains:
      - 'Login Data'
      - 'logins.json'
      - 'key4.db'
      - 'cookies.sqlite'
  filter_browser:
    Image|endswith:
      - '/Google Chrome'
      - '/Google Chrome Helper'
      - '/Microsoft Edge'
      - '/firefox'
      - '/Brave Browser'
      - '/Chromium'
  condition: sel_files and not filter_browser
falsepositives:
  - Backup- und Migrationswerkzeuge sowie Admin-Skripte, die Browserprofile kopieren - bekannte Prozesse und Konten als Baseline ausnehmen
level: medium

Grenzen der Erkennung

• Kompilierte Stealer hinterlassen keine Kommandozeile. Ein Binary, das die Datenbank direkt öffnet und in Prozessspeicher entschlüsselt, erscheint in keiner process_creation-Regel mit dem Dateinamen. Dafür braucht es Dateizugriffs-Telemetrie: SACL und Event 4663 unter Windows, auditd-Watches unter Linux, ESF-Dateiereignisse über eine EDR unter macOS.
• Der Lesezugriff auf das Original ist unter Windows ohne SACL unsichtbar. Sysmon sieht nur die Kopie (Event 11), nicht das Lesen. Wer die Datenbank in den Speicher liest und nie auf die Platte schreibt, bleibt ohne SACL oder EDR unentdeckt.
• Die Entschlüsselung selbst erzeugt kein Ereignis. DPAPI unter Windows, der Schlüsselbund unter Linux und die Keychain-Schnittstelle unter macOS protokollieren die Entschlüsselung des Browser-Schlüssels nicht als auswertbares Standardereignis. Sichtbar ist der Prozess, der sie durchführt, nicht die Operation.
• Im Browser laufender Code. Eine bösartige Erweiterung oder ein in den Browser injizierter Code liest Cookies und Formulardaten innerhalb des Browserprozesses - für jede dieser Regeln ist das der Browser selbst. Das ist ein eigenes Thema und hier nicht abgedeckt.

Fehlalarme und Tuning

• Browser-Import. Edge liest beim ersten Start und beim Import die Chrome-Datenbank, Chrome importiert aus Firefox, und beide schreiben das Ergebnis in ihr eigenes Profil. Das ist der häufigste legitime Fremdzugriff und in Regel 1 durch den Profilfilter ausgenommen; in Dateizugriffs-Telemetrie gehören msedge.exe und chrome.exe als Leser der jeweils anderen Datenbank in die Baseline.
• Backup, Migration und Virenscanner. Sicherungsagenten, USMT und Profil-Migrationen kopieren ganze Benutzerprofile, Virenscanner lesen jede Datei. Diese Prozesse nach Name, Signatur und Zielpfad als Baseline hinterlegen, nicht die Regel entschärfen. Ein Backup kopiert das gesamte Profil - ein Stealer nur die Credential-Dateien.
• Entwickler und Test-Automatisierung. Selenium, Puppeteer und Playwright starten Browser mit Remote-Debugging. Für diese Hosts und Elternprozesse (node, python, java aus einem Projektverzeichnis) eine Ausnahme setzen; auf Arbeitsplätzen ohne Entwicklungsaufgaben bleibt Regel 2 scharf.
• Passwortmanager. Manche Passwortmanager importieren direkt aus den Browser-Datenbanken. Den Import-Prozess als Baseline aufnehmen und gegen eine neue, unbekannte Binärdatei mit demselben Verhalten abgrenzen.
• Kette schlägt Einzeltreffer. Datenbank plus Schlüssel plus Archiv plus ausgehende Verbindung durch denselben fremden Prozess ist die Alarmstufe - der einzelne Dateitreffer ist ein Prüffall.

Analysten-Checkliste

1. Welcher Prozess hat zugegriffen - der Browser, ein zweiter Browser (Import), ein Backup- oder Scan-Prozess, oder eine unbekannte Binärdatei beziehungsweise ein Skript? Pfad, Signatur und Elternprozess prüfen.
2. Hat derselbe Prozess auch den Schlüssel angefasst - Local State, key4.db, den Keychain-Eintrag "Chrome Safe Storage" oder den Schlüsselbund?
3. Wurde die Datenbank kopiert, und wohin? Eine Kopie in Temp oder Downloads ist ein Stealer-Muster, eine im Backup-Ziel nicht.
4. Gibt es danach ein Archiv, einen Klartext-Export oder eine ausgehende Verbindung des Prozesses?
5. Welche Konten sind betroffen? Die im Browser gespeicherten Anmeldungen und aktiven Sitzungen bestimmen, welche Passwörter zu wechseln und welche Sitzungen zu beenden sind.
6. Folgebezug prüfen: Gibt es seither Anmeldungen mit diesen Konten von neuen Geräten oder Adressen (Valid Accounts)?

Härtung

• Passwortspeicherung im Browser begrenzen. Per Richtlinie (Chrome- und Edge-Policies, Firefox-Policies) das Speichern von Passwörtern im Browser abschalten und einen Unternehmens-Passwortmanager vorgeben - dann gibt es in Login Data nichts zu holen.
• Sitzungen kurz halten. Gestohlene Cookies sind nur so lange wert, wie die Sitzung lebt. Kurze Sitzungsdauern, gerätegebundene Sitzungen (Token Binding, Conditional Access mit Gerätebindung) und das Beenden aller Sitzungen bei Verdacht entwerten die Beute.
• Plattformschutz nutzen. Unter Windows aktuelle Browser mit App-Bound Encryption, unter macOS eine gesperrte Keychain und TCC, unter Linux einen laufenden Schlüsselbund statt des Standardschlüssels - und bei Firefox ein Hauptpasswort, wo der Browser überhaupt Passwörter speichern darf.
• Dateizugriff sichtbar machen. Unter Windows die SACL auf die Profildateien (siehe Infostealer erkennen), unter Linux auditd-Watches auf die Profilverzeichnisse, unter macOS eine EDR mit ESF-Dateiereignissen - ohne Dateizugriffs-Telemetrie bleibt der stille Stealer unsichtbar.

Der Test im Lab

Die Erkennung lässt sich auf isolierten Testsystemen mit einem Wegwerf-Browserprofil gefahrlos prüfen, ohne echte Schadsoftware und ohne echte Zugangsdaten:

• Für Regel 1 unter Windows die Datei Login Data eines Testprofils per Kopieren in ein Temp-Verzeichnis legen. Sysmon Event 11 muss die Kopie zeigen und die Regel greifen; eine Kopie innerhalb von User Data darf nicht auslösen.
• Für Regel 2 Chrome oder Edge aus einer PowerShell mit --remote-debugging-port=9222 und einem Test-Profilpfad starten und den Prozesstreffer kontrollieren.
• Für Regel 3 unter Linux mit auditd-Watch auf dem Testprofil ein sqlite3 gegen die Kopie der Login-Data-Datei absetzen. Der auditd-Datensatz muss den Zugriff mit exe zeigen, die Prozess-Regel greifen; secret-tool lookup gegen den Chrome-Eintrag im Schlüsselbund ergänzen.
• Für Regel 4 unter macOS dasselbe mit eslogger: cp der Datenbank und ein security find-generic-password -wa Chrome, das die Keychain-Regel auslösen muss (den Keychain-Dialog im Test abbrechen).
• Breiter wird der Test mit den Fällen zu T1555.003 aus Atomic Red Team, die es für Windows, Linux und macOS gibt.

Fazit

Browser-Zugangsdaten sind auf allen drei Plattformen dasselbe Ziel mit drei verschiedenen Schlössern: DPAPI und App-Bound Encryption, Keychain, Schlüsselbund. Für die Erkennung ist das die wichtigste Einsicht, denn der Angreifer braucht immer Datei und Schlüssel - und der Verteidiger muss beide Zugriffe sehen, um aus einem mehrdeutigen Dateitreffer einen belegten Diebstahl zu machen. Die vier Regeln liefern die Glieder dieser Kette als ehrliche Zugriffsindikatoren, die Dateizugriffs-Telemetrie der jeweiligen Plattform liefert den Rest. Die wirksamste Härtung ist, dem Browser das Speichern von Passwörtern abzugewöhnen und Sitzungen kurz zu halten. Die Windows-Seite mit SACL und DPAPI vertieft Infostealer erkennen, den macOS-Schlüssel behandelt Keychain-Zugriff erkennen, andere Wege zu Windows-Zugangsdaten stehen unter Mimikatz und LSASS-Dump.