Cache, privates Surfen und verbleibende Spuren

Die Lektionen 4.1 und 4.2 behandelten die Auswertung der Verlaufsdatenbanken. Diese Lektion behandelt den Browser-Cache, der Kopien der tatsächlich ausgelieferten Inhalte speichert, und das private Surfen, bei dem Verlauf und Cache entfernt werden, nicht jedoch die Spuren, die Windows außerhalb des Browsers speichert. Der Prüfer muss wissen, welche Spuren verbleiben, wo sie zu finden sind und welche Schlussfolgerungen sie zulassen.

Was der Cache enthält und warum das wichtig ist

Ein Browser speichert Kopien von Seiten, Bildern, Skripten, Stylesheets und anderen heruntergeladenen Inhalten, damit er sie erneut anzeigen kann, ohne sie nochmals abzurufen. Jeder Cache-Eintrag enthält den Schlüssel (im Wesentlichen die URL), den Inhalt selbst und die Antwortheader des Servers, etwa Date (wann der Server die Antwort gesendet hat), Last-Modified, Content-Type, Content-Length und ETag, sowie Zeitangaben, die der Browser anhand der lokalen Uhr schreibt. Dadurch erhält der Prüfer drei Dinge, die die Verlaufsdatenbank nicht liefert: den Inhalt, den der Benutzer gesehen hat, einen Nachweis dafür, dass der Inhalt dieses Browserprofil erreicht hat, und einen Zeitstempel von der Uhr des Servers.

Der Header Date wird vom Webserver geschrieben, dessen Uhr normalerweise synchronisiert ist, und dient daher als nützliche externe Zeitreferenz; eine aus einem CDN- oder Proxy-Cache ausgelieferte Antwort behält ihren ursprünglichen Date-Wert, und ein Header Age zeigt dann an, wie alt sie ist. Vergleichen Sie diesen Wert mit den lokalen Zeitangaben desselben Eintrags, um die Abweichung der Geräteuhr zu bestimmen (Lektion 3.5). Last-Modified liefert eine zeitliche Untergrenze: Der Inhalt kann nicht ausgeliefert worden sein, bevor er zuletzt auf dem Server geändert wurde.

Chromium-Cache

Chrome speichert seinen HTTP-Cache unter %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache\Cache_Data; Edge verwendet dieselbe Struktur unter %LOCALAPPDATA%\Microsoft\Edge\User Data\<profile>. Das Format auf dem Datenträger variiert je nach Plattform und Version. Neuere Chrome-Versionen unter Windows verwenden in Cache_Data das Blockfile-Format:

Jeder Eintrag besitzt Stream 0 (die geparsten HTTP-Antwortinformationen einschließlich der Header) und Stream 1 (den Antwortinhalt, häufig noch wie bei der Übertragung mit gzip oder Brotli komprimiert). Chromium speichert Zeitangaben als Mikrosekunden seit 1601-01-01 UTC. Unter Android, Linux, ChromeOS und macOS verwendet Chromium stattdessen standardmäßig das Format Simple Cache: eine Datei pro Eintrag mit dem Namen <16 hex digits>_0, optionalen Dateien mit den Endungen _1 und _s sowie einem Ordner index-dir.

Seit Chrome 86 ist der HTTP-Cache nach Websites partitioniert. Daher können Schlüssel mit einem Präfix wie 1/0/_dk_ beginnen, gefolgt von der Website der obersten Ebene, die die Ressource geladen hat. Dieses Präfix gibt an, für welche Seite ein Bild oder Skript eines Drittanbieters geladen wurde.

Zwei benachbarte Ordner werden häufig mit dem Cache verwechselt. Code Cache (Unterordner js und wasm) enthält kompiliertes JavaScript und WebAssembly mit der Skript-URL als Schlüssel: Er zeigt, dass die Skripte einer Website ausgeführt wurden, nicht aber, was angezeigt wurde. GPUCache enthält kompilierte Grafik-Shader und hat nur geringen Beweiswert.

Firefox cache2

Firefox 32 und höher verwenden das cache2-Format im lokalen Profil (nicht im Roaming-Profil): %LOCALAPPDATA%\Mozilla\Firefox\Profiles\<profile>\cache2\entries. Jeder Eintrag besteht aus einer Datei, deren Name der aus 40 Hexadezimalziffern bestehende SHA-1-Hash ihres Schlüssels ist. Die Datei enthält zuerst den Inhalt, dann die Metadaten: Hashes der Datenblöcke, einen Header (Version, Abrufanzahl, letzter Abruf, letzte Änderung, Frecency, Ablaufzeit, Schlüsselgröße, Flags), den mit der URL endenden Schlüssel (mit vorangestellten kurzen Flags wie a,:) und benannte Elemente wie request-method und response-head, das die vollständigen Antwortheader enthält. Die letzten 4 Bytes sind ein Big-Endian-Offset zum Beginn der Metadaten, der der Inhaltslänge entspricht. Die Zeitangaben im Header sind 32-Bit-Unix-Sekunden in Big-Endian-Reihenfolge. cache2\index fasst alle Einträge zusammen (Hashes, Frecency, Flags) und enthält keine URLs.

Durchgerechnetes Beispiel: Auslesen eines cache2-Eintrags

Eine Eintragsdatei ist 15.240 Bytes lang. Ihre letzten 4 Bytes sind 00 00 3A 98 = 0x3A98 = 15.000. Die Bytes 0 bis 14.999 sind somit der zwischengespeicherte Inhalt (sie beginnen mit 89 50 4E 47, einer PNG-Signatur), und die Metadaten beginnen bei Offset 15.000. Das Feld für den letzten Abruf enthält 69 B5 60 85 = 1.773.494.405 Sekunden seit 1970-01-01 = 2026-03-14T13:20:05Z. Das Element response-head enthält Date: Sat, 14 Mar 2026 13:20:03 GMT. Die lokale Uhr und der Server stimmen bis auf 2 Sekunden überein, was zur normalen Übertragungsdauer passt. Für diesen Zeitraum ist daher keine Korrektur der Uhrabweichung erforderlich.

Werkzeuge und Grenzen

Kostenlose Beispiele: NirSoft ChromeCacheView und MozillaCacheView listen URL, Inhaltstyp, Serverzeit und Zeitpunkt der letzten Änderung auf und exportieren den Inhalt; Plaso bietet die Parser chrome_cache und firefox_cache2; Hindsight parst den Chromium-Cache zusammen mit dem Verlauf. Unabhängig vom Werkzeug sollten Sie einen Eintrag manuell öffnen und die Zeitangaben überprüfen.

Ein Cache ist begrenzt. Browser bestimmen seine Größe anhand von Einstellungen oder des freien Speicherplatzes und verdrängen die am längsten nicht verwendeten Einträge; Antworten mit Cache-Control: no-store, wie sie bei Banking- und Anmeldeseiten üblich sind, werden nie geschrieben; außerdem kann der Benutzer den Cache leeren. Das Fehlen eines Cache-Eintrags ist kein Beweis dafür, dass eine Seite nicht besucht wurde.

Privates Surfen

Chrome Incognito, Edge InPrivate und Firefox Privates Surfen funktionieren grundsätzlich auf dieselbe Weise. Der Browser schreibt weder Verlauf noch Downloadliste, Formulardaten oder Sucheinträge; Cookies und Website-Daten befinden sich im Arbeitsspeicher und werden verworfen, sobald das letzte private Fenster geschlossen wird; und der HTTP-Cache wird im Arbeitsspeicher statt in Cache_Data oder cache2 gehalten. Alle drei behalten in einem privaten Fenster heruntergeladene Dateien und darin erstellte Lesezeichen (Favoriten) bei, da diese außerhalb der privaten Sitzung gespeichert werden. Der private Modus schützt vor dem nächsten Benutzer des Profils, nicht vor dem Betriebssystem, dem Netzwerk oder den besuchten Websites.

Die verbleibenden Spuren liegen daher außerhalb der eigenen Datenbanken des Browsers:

Folgende Punkte müssen Sie präzise anwenden:

• Zone.Identifier. Bei einem Download in einem normalen Fenster schreibt Chromium unter Windows 10 und 11 HostUrl und ReferrerUrl. Bei einem Incognito-Download übergibt es die URL nicht: Der Stream behält ZoneId=3, aber HostUrl enthält den Platzhalter about:internet, und ReferrerUrl fehlt. Überprüfen Sie das Verhalten der Version in Ihrem Fall mit einem Testdownload.
• Prefetch und BAM belegen, dass chrome.exe oder firefox.exe ausgeführt wurde, nicht, dass ein privates Fenster verwendet wurde. Prefetch zeichnet keine Befehlszeilenargumente auf. Eine Option wie --incognito erscheint daher nur dort, wo Befehlszeilen protokolliert werden, etwa im Sicherheitsereignis 4688 bei aktivierter Befehlszeilenüberwachung; ein Fenster, das mit Ctrl+Shift+N in einem bereits laufenden Browser geöffnet wird, wird überhaupt nicht mit dieser Option gestartet.
• DNS-Clientcache. Auf einem laufenden System listet ipconfig /displaydns die Namen auf, die der Windows-DNS-Client aufgelöst hat; der Cache ist flüchtig und nach einem Neustart verschwunden. Ein Browser, der Namen selbst auflöst, beispielsweise Chrome mit aktiviertem integriertem Resolver, kann diesen Cache umgehen. Ein Browser, der DNS over HTTPS verwendet, umgeht außerdem die Protokolle des lokalen DNS-Servers.
• Netzwerkprotokolle zeigen gewöhnlich Hostnamen, keine vollständigen URLs: Bei HTTPS protokolliert ein Proxy ohne Entschlüsselung Host und Port der CONNECT-Anfrage, nicht den Pfad.

Ein gelöschter Verlauf ist kein privates Surfen

Beim Löschen des Verlaufs werden zuvor geschriebene Zeilen gelöscht; beim privaten Surfen werden sie nie geschrieben. Dieser Unterschied ist wichtig, weil gelöschte Zeilen erhalten bleiben können. Bei einer allgemeinen SQLite-Implementierung landet eine gelöschte Zeile im freien Bereich innerhalb einer Seite oder auf einer Freelist-Seite, bis dieser Bereich wiederverwendet oder die Datenbank mit VACUUM bereinigt wird. Chromium und Firefox kompilieren SQLite jedoch mit aktiviertem Secure Delete, wodurch gelöschte Inhalte in der Hauptdatei mit Nullen überschrieben werden. Kopien können weiterhin im Rollback-Journal (History-journal bei Chromium) oder im Write-Ahead-Log (places.sqlite-wal bei Firefox), in Volumenschattenkopien und in den $UsnJrnl-Datensätzen der zum Zeitpunkt der Bereinigung gelöschten Cache-Dateien verbleiben. SRUM und Prefetch werden von der Löschfunktion des Browsers überhaupt nicht verändert.

Einen Befund aus indirekten Spuren formulieren

Wenn nur indirekte Spuren vorliegen, nennen Sie jede Quelle und ihre Grenzen, und stellen Sie die Nutzung eines privaten Fensters nicht als Tatsache dar, solange nichts sie belegt. Geeignete Formulierung: „Die Spuren sind mit dem Aufruf von transfer.example.com in einem privaten Fenster vereinbar; der Browserverlauf selbst enthält keinen Eintrag zu dieser Website.“ Führen Sie anschließend die geprüften Alternativen auf: ein anderer Browser oder ein anderes Profil, ein gelöschter Verlauf oder ein anderes Gerät.

Durchgearbeitetes Beispiel: ein Beleg ohne Verlauf

Eine Windows-11-Triage-Datensammlung aus einem anderen Fall zeigt für den Benutzer lferraz:

• Chrome History: kein Besuch oder Download für transfer.example.com. Der früheste Besuch in der Datenbank ist 2026-04-21T15:02:41Z.
• C:\Users\lferraz\Downloads\upload-receipt.pdf, $SI-Erstellungszeit 2026-04-21T13:41:07Z, mit Zone.Identifier ZoneId=3, ReferrerUrl=https://transfer.example.com/upload/done, HostUrl=https://transfer.example.com/r/8f3a/upload-receipt.pdf.
• SRUM Network Data Usage für chrome.exe, Benutzer lferraz, Intervallende 14:00:00Z (vorherige Zeile 13:00:00Z): BytesSent 734.003.200, BytesRecvd 9.437.184.
• Cache_Data enthält nur index und neue Dateien data_0 bis data_3 ohne Einträge, erstellt am 2026-04-21T15:01:58Z.

Berechnung. 734.003.200 ÷ 1.048.576 = 700 MiB gesendet und 9.437.184 ÷ 1.048.576 = 9 MiB empfangen zwischen 13:00:00Z und 14:00:00Z, ein Verhältnis von etwa 78:1, das zu einem Upload passt. Der Download um 13:41:07Z liegt innerhalb dieses Intervalls.

Was sich daraus schließen lässt. Eine Datei wurde um 13:41:07Z von einer URL auf transfer.example.com gespeichert, nachdem eine Seite dieser Website (/upload/done) aufgerufen worden war. chrome.exe sendete unter lferraz in derselben Stunde etwa 700 MiB.

Was die Hypothese des privaten Surfens erklären muss. Die tatsächliche HostUrl spricht gegen einen Chrome-Incognito-Download, bei dem about:internet aufgezeichnet worden wäre. Ein um 15:01:58Z neu erstellter Cache und ein Verlauf, der um 15:02:41Z beginnt, passen zu einer Löschung der Browserdaten kurz vor 15:02, nicht zu privatem Surfen, das den normalen Cache unverändert lässt. Nächste Schritte: Suchen Sie mittels Carving in History-journal, nicht zugeordnetem Speicherplatz und Schattenkopien nach älteren History-Seiten, prüfen Sie $UsnJrnl auf gelöschte f_-Dateien um 15:01Z und untersuchen Sie Edge sowie andere Chrome-Profile, da ein anderer Chromium-Browser denselben Stream geschrieben haben könnte.

Was sich daraus nicht schließen lässt. Weder SRUM noch Zone.Identifier geben an, was hochgeladen wurde oder ob die 700 MiB an transfer.example.com gingen; SRUM enthält kein Ziel. Für diese Zuordnung sind Proxy- oder DNS-Protokolle aus dem Netzwerk erforderlich.

Prüfungsschwerpunkt: Rechnen Sie damit, die URL, den Date-Header oder den Inhaltstyp eines Cache-Eintrags auszulesen oder den Metadaten-Offset eines Firefox-cache2-Eintrags aus den letzten 4 Bytes zu berechnen. Sie sollten auswählen können, welche Artefakte nach privatem Surfen erhalten bleiben, eine HostUrl oder eine SRUM-Byteanzahl angeben und erkennen, dass eine tatsächliche HostUrl bei einem Chromium-Download nicht zu Incognito passt. Fragen können einen gelöschten Verlauf (Kopien möglicherweise wiederherstellbar) dem privaten Surfen (nichts geschrieben) gegenüberstellen.

Kernpunkte

• Cache-Einträge enthalten den Inhalt, den URL-Schlüssel und die Antwortheader des Servers; der Date-Header dient als externe Zeitreferenz zur Prüfung von Uhrabweichungen.
• Chrome unter Windows verwendet das Blockfile-Format in Cache_Data (index, data_0 bis data_3, f_-Dateien); Firefox 32+ verwendet eine Datei in cache2\entries pro Eintrag, wobei die Metadaten auf den Inhalt folgen.
• Caches sind größenbegrenzt, speichern keine no-store-Antworten und können geleert werden. Ein fehlender Eintrag beweist daher nichts.
• Beim privaten Surfen werden weder Verlauf noch Cookies, Formulardaten oder Datenträger-Cache geschrieben, doch Downloads, Lesezeichen, Prefetch, BAM, SRUM, LNK-Dateien, Arbeitsspeicher und Netzwerkprotokolle bleiben erhalten.
• Chrome-Incognito-Downloads enthalten ZoneId=3 mit HostUrl=about:internet; eine tatsächliche URL deutet auf eine andere Herkunft hin.
• Ein gelöschter Verlauf wird durch Secure Delete in der Hauptdatenbank mit Nullen überschrieben, kann aber in Journalen, WAL-Dateien und Schattenkopien erhalten bleiben; privates Surfen hinterlässt dort nichts.