DEL III: PROBLEMET OPSTOD IGEN
Gentagelsen den 10. september, bevarede sikkerhedskopier før og efter hændelsen, Hostingers scannerregistreringer og bevaringsforløbet den 11. september.
Gentagelsen i september dokumenteres separat, fordi den fandt sted efter, at Hostinger allerede havde udsendt sin afsluttende interne gennemgang. Den stærkeste del af dette materiale er den uafhængige grænse før og efter den nye scannerhandling.
En klar registrering før hændelsen
En Hostinger-sikkerhedskopi fra 10. september kl. 07.09 bevarer manager.php i Jurist-roden på 548.265 bytes. En uafhængig sikkerhedskopi fra samme dag bevarer præcis den samme fil byte-for-byte. De to uafhængige kilder fastslår filens tilstand før den nye malwarehændelse uden at være afhængige af en rekonstruktion baseret på Hostinger-supportudsagn.
Scannerhændelsen
Hostingers malware-interface registrerer en ny hændelse for manager.php som Malicious med handlingen Removed. Datoen i interfacet og backend-tidsstemplerne, som support senere viste, bevares nøjagtigt som registreret, fordi systemerne kan repræsentere forskellige trin eller tidszoner. Sagsmappen tvinger dem ikke stiltiende sammen til ét tidspunkt.
Registreringen efter hændelsen
En Hostinger-sikkerhedskopi fra 11. september kl. 07.11 bevarer samme manager.php-sti med 0 bytes. Live-filen var også 0 bytes, da hændelsen blev observeret. Den dokumenterede rækkefølge omfatter dermed en komplet fil før hændelsen, scannerhændelsen og en efterfølgende Hostinger-sikkerhedskopi af samme sti med 0 bytes.
Support viste backend-metadata, men kunne ikke forklare dens semantik
Den 11. september viste en supportvendt registrering den nøjagtige sti, en registreret hash, en registreret størrelse på 0 bytes, klassifikationen malicious, status quarantined, et karantænetidspunkt, et audittidspunkt og et cleanup-tidspunkt sat til null. Support kunne ikke fastslå, om den registrerede hash og størrelsen på 0 bytes beskrev det samme objekt eller samme trin i livscyklussen. Den offentlige dokumentation bevarer denne usikkerhed i stedet for at levere en spekulativ forklaring.
Bevaring blev et nyt spørgsmål den 11. september
Menneskelig support bekræftede, at den udtrykkelige anmodning om bevaring og retention hold var registreret i klage #137820. Senere udsagn adskiller den registrerede anmodning fra den faktiske anvendelse af et hold. Kl. 17.40 CEST havde Hostinger-support fortsat ikke bekræftet den faktiske anvendelse af hold, en intern hold-reference eller forlænget opbevaring af et eventuelt bevaret original- eller karantæneobjekt.
Bevaringskronologien indeholder en konflikt, som fortsat er uafklaret
Kl. 17.02 CEST sagde en menneskelig agent, at den udtrykkelige instruktion om ikke-udløb endnu ikke var sendt. Kl. 17.33 sagde den samme agent, at den var sendt kl. 14.35 UTC, svarende til kl. 16.35 CEST. Det angivne afsendelsestidspunkt ligger dermed før beskeden om, at instruktionen endnu ikke var sendt. Begge udsagn bevares, som de blev givet. Sagsmappen udleder ikke hensigt og opfinder ikke en forklaring på uoverensstemmelsen.
Den proceduremæssige status ændrede sig også efter gentagelsen
Hostinger beskrev svaret den 7. september som afslutningen på den interne gennemgang. Efter den nye fjernelse den 10. september oplyste support den 11. september, at sagen fortsat var åben og under gennemgang af et specialiseret teknisk team. Udsagnene kan vedrøre forskellige proceduremæssige stadier, så den offentlige dokumentation bevarer begge uden at fremstille dem som én samlet bekræftet status.