Layer-7-Angriff auf Filterkombinationen: ein technisches Post-Mortem

Am 4. Oktober 2026 fiel eine von IT4OWL selbst betriebene Vergleichsplattform aus. Es ist kein Kundenfall: IT4OWL betreibt die Plattform selbst, sie wird nicht benannt, es sind unsere eigenen Daten.

Was Betreibern mit einem ähnlichen Problem am meisten nützt: Bandbreite war nicht der Engpass. In der stärksten Stunde des erfassten Zeitraums kamen nach Schätzung von Cloudflare rund 74.400 Anfragen an, im Schnitt etwa 21 pro Sekunde. Die Quelladressen wechselten fast mit jeder Anfrage, Limits pro Adresse konnten deshalb nicht wirken. Und praktisch jede Kombination wurde höchstens zweimal abgerufen, kein Cache konnte helfen. Teuer war nicht eine einzelne langsame Anfrage, sondern die Rate, mit der neue Kombinationen eintrafen.

Wer hinter dem Verkehr stand, lässt sich aus den Daten nicht ableiten.

Alle Zeiten UTC. Die Berlin-Zeit steht in Klammern mit Zonenangabe: MESZ (UTC+2) bis zum 25. Oktober 01:00 UTC, danach MEZ (UTC+1).

Die Vergleichsseite wird bei jeder Anfrage serverseitig gerendert, sobald die Adresse eine Hauptauswahl und optionale Zusatzfilter enthält. Der Verkehr variierte beides über den gültigen Wertebereich der Oberfläche, einschließlich älterer Kombinationen, die der Parser noch akzeptiert. Jede Anfrage war gültig.

Jede neue Kombination ist ein Cache-Miss: Datenbankabfragen für die Ergebnisse und mehrere Facettenzählungen, danach ein serverseitig gerenderter HTML-Aufbau. Der Cache für fertige Ergebnisse war begrenzt. Die Liste der noch laufenden Abfragen hatte pro Kombination keine Obergrenze und entdoppelte nur identische Abfragen. Der Datenbank-Pool hatte 16 Verbindungen und 20 Sekunden Wartebudget. Das Anwendungsprotokoll vom 4. Oktober enthält 19.089 Zeitüberschreitungen beim Beschaffen einer Verbindung und 1.893 unbehandelte Promise-Rejections, und es endet mit JavaScript-Heap-Erschöpfung bei rund 1,9 GB Heap, Abbruch, Exit-Code 134. Es war kein Kernel-OOM-Kill, der Host hatte freien Speicher. Plausibel ist: Viele einmalige Kombinationen erzeugen wartende Arbeit schneller, als der Pool sie abarbeitet, und diese Arbeit liegt auf dem Heap. Bewiesen ist das nicht; ein Heap-Profil, das diesen Pfad als alleinige Ursache zeigt, gibt es nicht.

Wie neu waren die Kombinationen?

Auf 100 Filteranfragen kamen rund 64 verschiedene URLs: 858.982 verschiedene URLs bei 1.338.251 filterförmigen Datensätzen. Das ist nicht der Anteil der nur einmal gesehenen URLs. Für den 4. bis 6. Oktober, an dem die Datensätze nahezu vollständig sind, gilt: 936.476 Filter-Datensätze, 565.127 verschiedene URLs, 99,7 % der Datensätze trafen eine URL, die höchstens zweimal vorkam, und 20,8 % eine URL, die genau einmal vorkam. Die meisten Kombinationen wurden genau zweimal abgerufen. Im Fehlerprotokoll des Origins vom 4. Oktober tragen 140.705 fehlgeschlagene Anfragen 82.951 verschiedene URLs, davon 57.089 genau zweimal (ungesampelt). Vorbehalt: Eine in der Stichprobe einmal gesehene URL kann öfter angefragt worden sein.

Verkehrsvolumen und Bandbreite

Die stärkste Stunde des erfassten Zeitraums (4. Oktober, 17:00–18:00 UTC) brachte nach Schätzung rund 74.400 Anfragen, die stärkste Minute rund 4.960 (30. September, 20:08 UTC). Die ausgelieferte Datenmenge lag in keiner Stunde über 1,31 GB, im Stundenmittel 2,9 Mbit/s (29. September, 22:00 UTC). In der Ausfallstunde am 4. Oktober waren es 0,43 GB, etwa 1 Mbit/s; über die 31 Tage wurden 114,7 GB ausgeliefert. Stundenmittel verbergen kurze Spitzen. Edge-Daten vor dem 27. September 08:15 UTC existieren nicht.

Ein Adresspool, der fast pro Anfrage wechselte

Am 6. Oktober stammten 469.726 filterförmige Datensätze von 366.865 verschiedenen Quelladressen: 1,28 Anfragen pro Adresse, 80 % der Adressen genau einmal, die aktivste Adresse sandte 69. Am 4. Oktober waren es 254.856 Datensätze von 219.829 Adressen (1,16 pro Adresse, aktivste 34). Über das gesamte Fenster kamen mindestens 897.554 verschiedene Quelladressen vor (Untergrenze wegen der Stichprobe). Im Fehlerprotokoll vom 4. Oktober hatte der häufigste Client-Wert 39 von 140.705 Fehlern. Ratenlimits und Sperren pro Adresse laufen bei dieser Streuung ins Leere. 97,9 % der Filter-Datensätze (1.310.134 von 1.338.251) kamen von Ausgängen, die Cloudflare außerhalb von DE, AT und CH verortet; das beschreibt Ausgangsorte, nicht die Herkunft des Verkehrs.

Der Ausfall am 4. Oktober

Erster Upstream-Timeout 16:39:49 UTC, erste abgewiesene Verbindung 17:07:10 UTC, letzte 20:27:47 UTC, neuer Prozess um 20:30:27 UTC. Von 17:00 bis 20:59 UTC endeten 91,6 % aller Anfragen am Edge in einem 5xx (140.308 von rund 153.100, Cloudflare-Schätzung). Das Origin zählte an diesem Tag 140.689 Upstream-Fehler, davon 140.495 abgewiesene Verbindungen; beide unabhängigen Quellen stimmen innerhalb von 0,3 % überein. Die schlimmste Minute zählte 1.986 fehlgeschlagene Anfragen (17:38 UTC).

Kosten pro Anfrage

Unter Normallast (1. Oktober bis 4. Oktober 15:59 UTC) brauchte eine erfolgreiche Filteranfrage am Origin im Median 678 ms (p95 2,25 s), eine normale Seite ohne Query 623 ms (p95 3,09 s): etwa das 1,1- bis 1,3-Fache. Nach der Wiederinbetriebnahme (18. bis 28. Oktober, geringe Last) lag der Median einer erfolgreichen Filteranfrage bei 1.011 ms, gegenüber 678 ms in der Normallast; die Daten erklären den Unterschied nicht. Von 16:00 bis 17:59 UTC am 4. Oktober brauchten die noch erfolgreichen normalen Seiten im Median 5,0 s (p95 21 s), gegenüber 0,6 s und 3,1 s an den Tagen davor (12.752 Datensätze). Die 5,0 s und 21 s beruhen nur auf 87 Datensätzen. Die statische Antwort dauerte im Median 265 ms (p95 0,94 s), etwa das 2,6- bis 3-Fache schneller als eine gerenderte Filterseite.

Erkennung am Edge: die Hälfte. Am Abend des 4. Oktober kam eine schmale Cloudflare-Signatur für das beobachtete Client-Profil hinzu. Im Fenster 5. Oktober 18:00 bis 6. Oktober 16:59 UTC wurden 308.119 von 608.882 filterförmigen Datensätzen am Edge blockiert (50,6 %). Die andere Hälfte hatte ihre Anfragemerkmale geändert, erreichte das Origin und löste am Nachmittag des 5. Oktober allein den Neustart-Sturm aus. Erkennung allein reichte nicht; entscheidend war, dass erkannte Anfragen nichts mehr kosteten.

Prozessüberwachung: aus dem Absturz wurde ein Neustart-Sturm. Am 4. Oktober startete nichts den Prozess neu; er wurde von Hand gestartet. Danach startete eine Prozessüberwachung die Anwendung bei Überschreiten einer Speichergrenze neu. Ab 16:05 UTC am 5. Oktober ging das im Minutentakt: Der Zähler stand um 17:26 UTC bei 94, um 17:29 bei 98 und um 17:57 bei 118. Er war am 4. Oktober gegen 21:05 UTC bei 0 gestartet, und bis 16:05 UTC am 5. Oktober zeigt das Origin-Protokoll nur zwei vereinzelte Verbindungsabweisungen, gegen 4.450 allein in der Stunde ab 16:00 UTC. Die 94 sind also der Sturm selbst: rund 94 Neustarts in seinen ersten 80 Minuten, rund 118 zwischen 16:05 und 17:57 UTC (24 in den 31 Minuten der Inspektion). Der Prozess lag bei 1,46–1,48 GB RSS, die mittlere HTTP-Latenz bei 3,1–3,6 s. Am Origin gab es an diesem Nachmittag 8.250 Upstream-Fehler, am Edge endeten nach Schätzung 12 % aller Anfragen von 16:00 bis 17:59 UTC in 5xx. Die Deduplizierungskorrektur vom 4. Oktober hatte keine messbare Wirkung.

Statische Antwort vor der Anwendung: Ende der Fehler. Ab etwa 17:45 UTC am 5. Oktober (19:45 MESZ) wurden Anfragen mit der Angriffsform im Webserver vor der Anwendung klassifiziert und mit einer vorgerenderten statischen Seite beantwortet, ohne Anwendungs- und Datenbankarbeit. Die Klassifikation arbeitet anhand der Form der Anfrage und weiterer Merkmale, direkt vor der Anwendung; das Ergebnis wird serverseitig gespeichert. Einzelheiten veröffentlichen wir nicht, weil die Regel sonst eine Anleitung zum Umgehen wäre. Die gespeicherte Variante ging gegen 17:55 UTC live; ihr erster Versuch schlug fehl und wurde einige Minuten auf die zustandslose Variante zurückgesetzt, die Maßnahme lief also nicht ohne Unterbrechung.

Gespeicherte Klassifikation: Absicherung, kein Arbeitspferd. Sie sollte verhindern, dass eine einmal erkannte Adresse nach geänderten Anfragen wieder die Anwendung belastet. In der intensivsten Phase (6. Oktober 08:44 bis 13:30 UTC) zeigen die Zähler mindestens 65.536 neu klassifizierte Anfragen gegen weniger als 512, die nur wegen einer gespeicherten Klassifikation statisch beantwortet wurden: unter 1 %. Die Zähler protokollieren in Zweierpotenzen, die Werte sind Schranken.

Die statische Seite zeigte keine Skripte, deshalb hinterlässt ein Nutzer, der sie bekam, kein Analytics-Ereignis. Das Protokoll der statischen Antworten hat keine Client-Angaben, und die Edge-Datensätze tragen keine Anfrage-Header. Wie viele echte Nutzer in diesen 23 Stunden die statische Seite sahen, lässt sich nicht messen. Die Daten begrenzen es aus mehreren Richtungen:

• Die Einordnung konnte nur direkte Aufrufe gespeicherter Filter-Links mit einem bestimmten Merkmalsprofil treffen. Wer über die Oberfläche der Seite filterte, bekam echte Ergebnisse. Betroffen sein konnte ein Nutzer, der einen gespeicherten Link direkt in diesem Profil öffnete oder von einer bereits als erkannt gespeicherten Adresse kam (geteilte Mobilfunk- oder Firmenausgänge).
• Ausgelöst nur wegen einer gespeicherten Adresse wurden vom 6. Oktober 08:44 UTC bis 7. Oktober 07:26 UTC weniger als 512 Antworten, gegenüber mindestens 65.536 Treffern der Signatur (bis 13:30 UTC). Mindestens 2.048 in Frage kommende Seitenaufrufe gelangten unklassifiziert zur Anwendung. Für die ersten 15 Stunden (5. Oktober 17:56 bis 6. Oktober 08:44 UTC) liefen die Zähler nicht; dafür gibt es keine Schranke.
• Von 5. Oktober 17:55 bis 6. Oktober 16:59 UTC bekamen 300.360 filterförmige Datensätze mit dem für die Klassifikation in Frage kommenden Client-Profil HTTP 200; das Origin protokollierte rund 295.587 statische Antworten. Mindestens 1.165 Datensätze mit anderen Profilen bekamen echte Daten von der Anwendung. Von den 300.360 kamen 5.633 (1,9 %) von Ausgängen in DE, AT oder CH, derselbe Anteil wie beim Angriff insgesamt (2,1 %). Das spricht nicht für einen Überschuss inländischer Nutzer; 5.633 ist eine Obergrenze, keine Schätzung echter Nutzer.
• Die normale Nutzung lief weiter: Die eigene Analytik zählte im Fenster 72 Sitzungen, 135 Seitenaufrufe, 48 Klicks und 5 Formularabsendungen, gegenüber 47 bis 49 Sitzungen in denselben 23-Stunden-Abschnitten am 1. bis 3. Oktober. Auch das erfasst keine Nutzer, die die statische Seite bekamen.

Teilweise beantwortbar. Der 29. September war kein gesunder Tag, sondern ein schwerer Brownout: In den stärksten Stunden (22:00–23:59 UTC) erreichten nach unserer Schätzung rund 45.600 bis 50.100 Filteranfragen pro Stunde das Origin (Stundenschätzung von Cloudflare mal Filteranteil der Datensätze mal nicht blockierter Anteil). Sie brauchten im Median 7,5 bis 10,0 s, das p95 lag bei rund 97 bis 99 s, die mittlere Origin-Zeit des gesamten Verkehrs bei 25,7 bis 26,5 s, und 31 bis 33 % der Filteranfragen endeten damit, dass der Client aufgab (Status 499). Am 4. Oktober um 17:00 UTC erreichten rund 73.700 Filteranfragen pro Stunde das Origin, etwa das 1,5-Fache. Zwischen beiden Tagen lag eine neue Anwendungsversion mit erweitertem Filterkatalog (30. September, 21:45 UTC); der Prozess, der am 4. Oktober abstürzte, lief mit ihr. Ob sie die Kosten pro Anfrage veränderte, wurde nicht gemessen. Nicht beantwortbar sind der Speicherspielraum (vor dem 4. Oktober gibt es keine Speichermesswerte) und ein Vergleich der Kombinationsraten (die Datensätze vom 29. September sind eine 1-zu-10-Stichprobe, die vom 4. Oktober nahezu vollständig).

Gegenüber dem 4. Oktober, als die Anwendung ausfiel:

• Filterförmige Datensätze pro Stunde am Edge: 74.325 (4. Oktober, 17 Uhr UTC; Gesamtverkehr dieser Stunde nach Schätzung 74.420 Anfragen) gegenüber 608.882 Datensätzen im gesamten Fenster 5. Oktober 18:00 bis 6. Oktober 16:59 UTC (ein Stundenmittel geben wir nicht an).
• 5xx am Edge, gesamter Verkehr: 91,6 % (4. Oktober, 17:00–20:59 UTC) gegenüber 0,003 % (16 von rund 634.000 Anfragen, Schätzung); 8 filterförmige Datensätze endeten in 5xx.
• Upstream-Fehler am Origin: 140.689 am 4. Oktober, 8.250 am Nachmittag des 5. Oktober, danach 1 (5. Oktober 18:00 bis 6. Oktober 16:59 UTC), bei 295.587 statischen Antworten (rund 12.500 bis 14.900 pro vollständiger Stunde ab 20:00 UTC am 5. Oktober).
• Neustarts: rund 118 in knapp zwei Stunden (5. Oktober, 16:05–17:57 UTC), danach 7 in rund 15 Stunden (Zähler 125 gegen 08:50 UTC am 6. Oktober).
• Anwendung: 1,46–1,48 GB RSS an der Grenze beziehungsweise Heap-Erschöpfung bei rund 1,9 GB gegenüber 608 MiB RSS und 27,7 % CPU um 17:59 UTC am 5. Oktober.
• Normale Seiten: 5,0 s / p95 21 s (n = 87) gegenüber 531 ms / p95 2,1 s.

Der Neustart-Sturm endete; Neustarts endeten nicht. Der Zähler stand am 8. Oktober um 03:12 UTC bei 135, in einem Intervall mit mindestens zwei absichtlichen Deployments. Die Ursache der Neustarts nach dem Sturm ist nicht dokumentiert.

• Stichprobe. Die Edge-Daten stammen aus Cloudflares Adaptive Analytics. Es gibt zwei Größen, die nicht addiert oder vermischt werden: die Schätzung von Cloudflare (rund 4,1 Mio. Anfragen im 31-Tage-Fenster, 27. September 08:15 UTC bis 28. Oktober 08:10 UTC) und 1,96 Mio. (1.963.348) einzeln ausgewertete Datensätze, deren Erfassung bis 28. Oktober 08:29:21 UTC lief. Warum das Fenster der Schätzung früher endet als das der Erfassung, halten die Unterlagen nicht fest. Vom 27. bis 30. September liegt nur etwa jede zehnte Anfrage als Datensatz vor; ab 1. Oktober folgen die Datensätze der Schätzung innerhalb weniger Prozent (0,94–0,98 an den Tagen 2. bis 6. Oktober), was auf eine fast vollständige Abdeckung hindeutet, aber keine Garantie ist. Für den 4. bis 6. Oktober gilt: rund eine Million Anfragen (Schätzung 1.002.210; Datensätze 979.982). Ungesampelte Rohprotokolle (Logpull, Logpush) standen auf diesem Konto nicht zur Verfügung.
• Filterförmig ist kein Urteil. Gezählt werden GET-Seitenaufrufe mit Filterparametern. Echte Nutzer verwenden Filter ebenfalls, und eine Basislinie vor dem Angriff liegt im aufbewahrten Fenster nicht vor. 1.338.251 filterförmige Datensätze (68 % von 1.963.348) sind keine Zahl von Angriffsanfragen, und Adressen sind keine Personen.
• Origin-Fehlerprotokolle zeichnen nur Fehlschläge auf, nicht alle Anfragen.
• Mechanismus nicht bewiesen. Der Pfad von Kombinationen über wartende Abfragen zur Heap-Erschöpfung ist aus Code und Protokollen plausibel; es gibt kein Heap-Profil.
• Warum die Welle endete, wissen wir nicht. Zwischen 16:40 und 16:55 UTC am 6. Oktober fielen die statischen Antworten von rund 1.000 pro fünf Minuten auf unter 100, das Edge-Volumen auf unter 500 Anfragen pro Stunde. Die Daten zeigen nicht, dass die statische Antwort das Ende verursacht hat.
• Ausfall vom 26. und 27. September. Siehe Zeitleiste: Die Ursache des Prozessendes ist nicht dokumentiert, und wir führen es nicht auf Filteranfragen zurück. Dass der Ausfall rund 26 Stunden dauerte, hat einen einfachen Grund: Niemand hat hingesehen. Es gab kein Monitoring und keine Alarmierung, bis eine Prüfung vor einem unabhängig geplanten Deployment ihn fand. Für diesen Zeitraum gibt es keine Edge-Daten.
• Abschaltung vom 8. bis 17. Oktober. Die Maßnahme hielt. Vom 8. bis 17. Oktober haben wir die Plattform trotzdem selbst vom Netz genommen: eine betriebliche Entscheidung, weil andere Projekte Vorrang hatten und wir abwägen wollten, ob sich der Weiterbetrieb als Angriffsziel lohnt. Diese Tage zählen weder als Ausfall durch den Angriff noch als ruhige Phase; die Messwerte in diesem Zeitraum sagen über den Angriff nichts.
• Zweites Speicherproblem. Nach der Rückkehr am 17. und 18. Oktober startete die Prozessüberwachung die Anwendung bei niedrigem Verkehr 5- bis 15-mal am Tag neu (18. Okt.: 5, 19. Okt.: 13, 20. Okt.: 15, 21. Okt.: 9). Die Grenze von 1.400 MiB lag innerhalb des normalen Arbeitsspeichers von 1,0 bis 1,5 GB, überwiegend nativer Speicher. Nach der Anhebung auf 1.800 MiB am 22. Oktober überschritt der Prozess sie am 23. Oktober noch zweimal. Bei keinem dieser Neustarts fand die Untersuchung eine Verkehrsspitze. Das ist ein eigenes Anwendungsproblem, keine Angriffsfolge, und es ist nicht gelöst.
• Spätere Kohorten. Ab dem 7. Oktober erschien eine kleine, wechselnde Kohorte auf einzelnen Inhaltsseiten (einige hundert Anfragen pro sechs Stunden). Vom 17. bis 22. Oktober wurden neue Kohorten mit drei schmalen Erweiterungen statisch oder mit bewusst verzögerter Fehlerantwort beantwortet; vom 18. bis 28. Oktober waren rund 96 % aller 5xx-Antworten am Edge solche Verzögerungsantworten, keine Ausfälle.
• Nicht gemessen: die Wirkung der gehärteten Anwendung vom 14. Oktober, da sie nach der Hauptwelle kam.

Bei der Inspektion am 30. September gab es auf dem Server weder eine Erreichbarkeitsprüfung noch einen Monitoring-Dienst, und bei keinem der beiden Ausfälle hat etwas Alarm geschlagen, auch am 4. Oktober nicht. Den Ausfall ab 26. September fand die Vorabprüfung eines unabhängig geplanten Deployments am 27. September, behoben durch den Neustart um 05:45 UTC: rund 26 Stunden unentdeckt. Den Ausfall am 4. Oktober haben wir selbst bemerkt. Die erste abgewiesene Verbindung war um 17:07:10 UTC, der erste protokollierte Untersuchungsstand um 20:27 UTC, der Neustart um 20:30:27 UTC. Wann wir den Ausfall bemerkten, ist nicht festgehalten, die Zeit bis zur Entdeckung betrug also höchstens rund 3 Stunden 20 Minuten. Der automatische Neustart existiert seit dem 4. Oktober gegen 21:05 UTC; eine vom Agenten ausgeführte Gesundheitsprüfung alle fünf Minuten läuft seit dem 6. Oktober 17:05 UTC (ab 8. Oktober sind 15 Minuten freigegeben).

• Eine Erreichbarkeitsprüfung von außerhalb des Servers, die einen Menschen alarmiert. Beide Ausfälle blieben ohne Alarm, der erste rund 26 Stunden lang; der unbemerkte Ausfall im September ist das deutlichste Argument für eine Prüfung von außen. Die Prüfung ruft die Seite alle paar Minuten von außen ab und meldet sich, wenn sie nicht antwortet. Ob das bei dieser Plattform schon läuft, belegen die Unterlagen nicht.
• Prozessüberwachung, die Neustarts meldet. Der automatische Neustart verhinderte den langen Ausfall und machte daraus rund 118 Neustarts in knapp zwei Stunden. Künftig soll die Überwachung jeden Neustart zählen und melden, sobald die Rate über dem Normalbetrieb liegt.
• Eine feste Obergrenze für die Liste laufender Abfragen. Sie hatte pro Kombination keinen Deckel und entdoppelte nur identische Abfragen; die Deduplizierungskorrektur vom 4. Oktober änderte daran nichts. Die Liste braucht eine feste Größe, statt auf dem Heap mit dem Verkehr zu wachsen. Ob die am 27. Oktober eingecheckten Änderungen zur Renderlast live sind, ist nicht verifiziert.
• Die Speichergrenze aus dem gemessenen Arbeitsspeicher ableiten. Die Grenze von 1.400 MiB lag im Normalbereich von 1,0 bis 1,5 GB und löste eigene Neustarts aus; auch 1.800 MiB wurden am 23. Oktober noch zweimal überschritten. Die Grenze muss aus der gemessenen Normalauslastung folgen, nicht aus einer Schätzung; das Problem ist nicht gelöst.
• Die vorgerenderte statische Antwort als erste Maßnahme bereithalten. Die Regel am Edge fing die Hälfte ab und wurde innerhalb eines Tages umgangen; erst die Klassifikation vor der Anwendung mit statischer Antwort beendete die Fehler. Beides sollte als fertige Vorlage bereitliegen, bevor die Erkennung verfeinert wird.
• Rohdaten-Export am Edge vor dem nächsten Vorfall einschalten und einen Normalwert festhalten. Auf diesem Konto standen Logpull und Logpush nicht zur Verfügung, es gibt nur Schätzungen und Stichproben, und keine Basislinie vor dem Angriff. Beides lässt sich nach dem Vorfall nicht nachholen.

Am 28. Oktober entstand ein Beweispaket mit 1.203 Dateien, rund 3,0 GB unkomprimiert, jede mit SHA-256-Prüfsumme und Größe aufgelistet. Das Erfassungsfenster am Edge reichte vom 27. September 08:15:59 UTC bis 28. Oktober 08:29:21 UTC in 466 zusammenhängenden Zeitfenstern, keines gekappt oder fehlgeschlagen, mit 1.963.348 Anfragedatensätzen und 197.837 Sicherheitsereignissen (überlappend, nie addiert). Ein separat gesicherter Stand vom 6. Oktober wurde erneut geprüft: alle 39 ursprünglichen Dateiprüfsummen stimmten überein. Das Paket enthält eine Kurzfassung, eine UTC-Zeitleiste, bei der jeder Eintrag als dokumentiert, vom Betreiber berichtet oder Hypothese gekennzeichnet ist, eine Datei zu Belegtem, Nichtbelegtem und verworfenen Spuren, Verkehrskohorten, Origin-Fehler in Fünf-Minuten-Abschnitten, Konfigurationsstände und das Inventar der Rohdaten. Originale und abgeleitete Dateien sind getrennt, Fehlschläge und verweigerte Zugriffe als Nachweis der Abwesenheit aufbewahrt. Wir erheben keinen Anspruch auf eine zertifizierte forensische Sicherung.