Et struktureret offentligt dokumentationsbibliotek for Hostinger-sagen med bilagsnumre, kildeangivelser, dokumentationsgrænser og links til den samlede tidslinje.
Den oprindelige augusthændelse, hvor manager.php blev klassificeret, og oprydningen efterlod den kundesynlige fil med 0 bytes.
Det forankrer den første destruktive hændelse og det efterfølgende forløb.
Det offentlige bilag fastslår ikke interne scannerforhold, som Hostinger ikke bevarede i sin hændelsestabel.
I am now submitting these details to our malware security team to create the persistent allowlist entry for both files.
Support oplyste, at de relevante hashes og stier var sendt til malware-teamet med henblik på permanent allowlist-behandling.
Hostinger bekræftede senere, at ingen allowlist nogensinde blev aktiveret, hvilket gør den tidligere oplysning central for vurderingen af håndteringen.
Det registrerer, hvad support oplyste kunden; det dokumenterer ikke i sig selv et internt allowlist-job.
No allowlist entry was ever activated; the submission was reviewed and declined by Imunify.
Hostinger erkendte, at den foreslåede allowlist aldrig blev aktiveret, og beskrev tilbuddet og tilbagetrækningen som en håndteringsfejl.
Det retter direkte den tidligere kundesynlige forståelse af, at permanent allowlist-behandling var i gang.
Det fastslår ikke i sig selv, hvorfor den tidligere oplysning blev givet.
En Hostinger-meddelelse henførte problemet til tiru.casa, selv om de berørte filer i hændelsesmaterialet lå andre steder.
Det indgår i den bredere dokumentation for inkonsekvent teknisk og administrativ håndtering.
Dokumentationen viser fejlhenføringen; den fastslår ikke den interne årsag.
Support brugte formuleringer om bekræftet backdoor og dropper og beskrev en Engineering- eller manuel verifikation den 14. august.
Disse udsagn ændrede væsentligt den forklaring, der fulgte efter den oprindelige håndtering som falsk positiv og allowlist.
Senere Hostinger-svar trak eller rettede væsentlige dele af denne forklaring.
There is no record of any Engineering scan, audit, command, or job on 14 August.
Hostinger oplyste, at der ikke fandtes nogen registrering af en Engineering-scanning, audit, kommando eller job den 14. august, der svarede til den tidligere fremstilling.
Det fjerner en central teknisk påstand, som tidligere blev brugt til at forklare hændelsen.
Tilbagetrækningen fastslår, at den beskrevne registrering ikke fandtes i Hostingers gennemgang; den fastslår ikke, hvorfor påstanden oprindeligt blev kommunikeret.
The detection was performed by Imunify360, through the Detect Admin Tools feature.
Hostinger trak den tidligere Monarx-angivelse tilbage og identificerede Imunify som det relevante detektionssystem.
Scannerens identitet er et grundlæggende teknisk forhold og ændrer, hvordan den tidligere forklaring skal læses.
Rettelsen afgør ikke i sig selv, om den kategoribaserede klassifikation var passende.
Correcting information communicated previously: the complete files were sent for analysis of a possible false positive, not just their hashes.
Hostinger præciserede, at hele filindholdet blev sendt gennem Imunify360, og ikke kun hashværdier.
For proprietær kildekode er forskellen mellem en hash og en komplet fil væsentlig for gennemsigtighed og tillid.
De bekræftede indsendelser vedrørte senere/aktuelle versioner den 18. august, ikke de oprindelige bytes før oprydningen den 7. august.
Each submission included the file path, server identifier, file owner, a note, and the complete file content via the Imunify360 submission tool to the CloudLinux API.
Hostinger oplyste, at komplette senere/aktuelle filer den 18. august blev sendt gennem Imunify360-værktøjet til falsk-positive indsendelser til CloudLinux API sammen med sti, serveridentifikator, filejer og en note.
Det dokumenterer, hvad der blev overført, og retter den tidligere kundeforståelse af, at kun hashes var involveret.
Spørgsmål om adgang, efterfølgende opbevaring, kopier, afledte versioner og den fulde chain of custody er fortsat særskilte forhold.
En kundesynlig eskaleringssamtale, som tidligere havde været synlig, forsvandt fra den brugervendte historik, mens ældre samtaler fortsat var synlige.
Den manglende samtale indeholder en del af den tekniske eskalering og førte til anmodninger om bevaring og forklaring.
Årsagen er fortsat uafklaret, og sagsmappen hævder ikke, at Hostinger fjernede samtalen for at skjule dokumentation.
Den formelle eskalering placerede de modstridende tekniske udsagn, spørgsmål om udlevering af registreringer og bevaringsanmodninger i en dokumenteret klagekanal.
Det fastslår, hvad Hostinger blev bedt om at forholde sig til før den afsluttende interne gennemgang.
En klage registrerer anmodninger og påstande; hvert faktuelt punkt afhænger fortsat af den underliggende dokumentation.
We know this has taken far longer than it should have, and that you have had to keep track of contradictions on our side that never should have reached you in the first place.
Hostinger afsluttede sin interne gennemgang, fastholdt den kategoribaserede fjernelsesposition, dokumenterede flere formelle rettelser, bekræftede overførsel af komplette filer til CloudLinux, oplistede væsentlige felter som manglede i den bevarede hændelsestabel og erkendte mangler i håndteringen.
Det er Hostingers mest omfattende udtalelse om augustforløbet før gentagelsen i september.
Den afsluttende gennemgang sletter ikke tidligere udsagn. Både tidligere udsagn og senere rettelser forbliver en del af kronologien.
Hostingers interface registrerer en ny hændelse for Jurist manager.php som Malicious med handlingen Removed efter den afsluttende interne gennemgang den 7. september.
Det fastslår, at samme type destruktive problem opstod igen, efter at Hostinger havde afsluttet sin interne gennemgang af augusttvisten.
Den viste interface registrerer klassifikation og handling; sikkerhedskopierne før og efter hændelsen fastslår filtilstandsgrænsen separat.
Hostinger-sikkerhedskopien før gentagelsen bevarer manager.php i roden som en ikke-tom fil på 548.265 bytes. En uafhængig sikkerhedskopi fra samme dag bevarer den samme fil byte-for-byte.
Det giver en uafhængigt bekræftet tilstand før hændelsen og den nye scannerfjernelse.
Den offentlige sagsmappe offentliggør ikke det proprietære kildekodearkiv eller enhver privat hashkorrelation.
Hostinger-sikkerhedskopien efter gentagelsen bevarer samme manager.php-sti med 0 bytes. Live-filen var også 0 bytes, da hændelsen blev observeret.
Sammen med H-014 og H-013 skaber det en klar dokumentarisk grænse mellem tilstanden før hændelsen, scannerhændelsen og tilstanden efter hændelsen.
Forskellige tidsstempler fra scanner-, audit-, karantæne- og backupsystemer bevares som registreret og udlignes ikke stiltiende.
Registreringen viste den nøjagtige sti, en registreret hash, registreret størrelse 0 bytes, klassifikationen malicious, status quarantined, karantænetidspunkt, audittidspunkt og et cleanup-tidspunkt sat til null.
Registreringen giver backend-vendt metadata, men viser også et semantisk hul, som support ikke kunne afklare.
Support kunne ikke fastslå, om hash og størrelsen på 0 bytes beskriver det samme objekt eller samme trin. En strategisk følsom, uafhængig hashkorrelation holdes foreløbig uden for den offentlige dokumentation.
Menneskelig support oplyste, at den udtrykkelige anmodning om bevaring og retention hold for septemberhændelsen var videresendt og registreret i klage #137820 på Hostingers angivne tidspunkt kl. 13.04.
Det fastslår, at en udtrykkelig bevaringsanmodning blev registreret i klagesagen.
Registrering af en anmodning er ikke det samme som bekræftelse af, at et hold faktisk blev anvendt.
Kl. 14.47 CEST oplyste menneskelig support, at Hostinger endnu ikke havde bekræftet, at selve bevaringsholdet var anvendt.
Det adskiller en registreret anmodning fra den faktiske gennemførelse af bevaringen.
Dette var en mellemstatus, som senere blev suppleret af yderligere udsagn fra menneskelig support den 11. september, herunder oplysninger der delvist modsiger hinanden.
En menneskelig agent oplyste kl. 17.02 CEST, at den udtrykkelige instruktion om at forhindre udløb eller sletning endnu ikke var sendt.
Udsagnet er relevant, fordi den samme agent senere angav et afsendelsestidspunkt, der ligger før denne besked.
Den offentlige dokumentation bevarer udsagnet uden at slutte, hvorfor den senere kronologi er i konflikt med det.
Kl. 17.33 CEST oplyste agenten, at instruktionen om ikke-udløb var sendt kl. 14.35 UTC, svarende til kl. 16.35 CEST. Det angivne afsendelsestidspunkt ligger før beskeden kl. 17.02 om, at instruktionen endnu ikke var sendt.
De to udsagn fra menneskelig support skaber en konflikt i den proceduremæssige kronologi, som forbliver en del af bevaringsforløbet.
Sagsmappen udleder ikke hensigt og vælger ikke en udokumenteret forklaring på konflikten.
Agenten kunne fortsat ikke bekræfte den faktiske anvendelse af hold, en intern hold-reference eller forlænget opbevaring af et eventuelt bevaret original- eller karantæneobjekt.
Dette er den seneste bevaringsstatus, der understøttes af materialet i det arkiv, der er leveret til offentliggørelse.
Det fastslår ikke, at dokumentation blev ødelagt, eller at bevaring blev afvist. Det fastslår, at den faktiske anvendelse af hold fortsat var ubekræftet på dette tidspunkt.