O bibliotecă publică structurată de dovezi pentru cazul Hostinger, cu identificatori de probă, note privind sursa, limite probatorii și legături către cronologia completă.
Evenimentul original din august în care manager.php a fost clasificat, iar operațiunea de curățare a lăsat fișierul vizibil clientului la 0 bytes.
Fixează primul incident distructiv și cronologia care a urmat.
Proba publică nu stabilește detalii interne ale scannerului pe care Hostinger nu le-a păstrat în tabelul de evenimente.
I am now submitting these details to our malware security team to create the persistent allowlist entry for both files.
Suportul a prezentat că hashurile și căile relevante fuseseră trimise echipei malware pentru gestionarea unui allowlist persistent.
Hostinger a confirmat ulterior că niciun allowlist nu a fost activat vreodată, ceea ce face afirmația inițială centrală pentru evaluarea modului de gestionare.
Înregistrează ce i-a spus suportul clientului; nu demonstrează independent existența unui job intern de allowlist.
No allowlist entry was ever activated; the submission was reviewed and declined by Imunify.
Hostinger a recunoscut că allowlist-ul propus nu a fost activat niciodată și a descris oferta și revenirea asupra ei drept un eșec de gestionare.
Corectează direct înțelegerea anterioară transmisă clientului, potrivit căreia allowlist-ul persistent era în curs de procesare.
Nu stabilește singur motivul pentru care afirmația inițială a fost făcută.
O notificare Hostinger a indicat un alt domeniu asociat planului de hosting, deși detectările contestate pentru manager.php priveau alte două locații de fișiere.
Documentează o neconcordanță în informația afișată clientului. Hostinger a explicat ulterior că numele provenea din eticheta domeniului principal al planului de hosting.
Explicația ulterioară arată cum spune Hostinger că a fost selectată eticheta domeniului; nu stabilește independent mecanismul intern care a generat notificarea.
Suportul a folosit formulări despre un backdoor confirmat și un dropper și a descris o verificare Engineering sau manuală din 14 august.
Aceste afirmații au schimbat substanțial explicația oferită după gestionarea inițială bazată pe fals pozitiv și allowlist.
Răspunsurile Hostinger ulterioare au retras sau corectat părți importante din această versiune.
There is no record of any Engineering scan, audit, command, or job on 14 August.
Hostinger a declarat că nu are nicio înregistrare privind o scanare Engineering, un audit, o comandă sau un job din 14 august care să corespundă afirmației anterioare.
Elimină o afirmație tehnică centrală folosită anterior pentru a explica incidentul.
Retragerea stabilește absența în analiza Hostinger a înregistrării prezentate anterior; nu stabilește motivul comunicării inițiale.
The detection was performed by Imunify360, through the Detect Admin Tools feature.
Hostinger a retras atribuirea anterioară către Monarx și a identificat Imunify drept sistemul relevant de detectare.
Identitatea scannerului este un fapt tehnic de bază și schimbă modul în care trebuie citită explicația anterioară.
Această corecție nu stabilește singură dacă clasificarea bazată pe categorie a fost adecvată.
Correcting information communicated previously: the complete files were sent for analysis of a possible false positive, not just their hashes.
Hostinger a clarificat că prin Imunify360 a fost transmis conținutul complet al fișierelor, nu doar valorile hash.
Pentru cod sursă proprietar, diferența dintre un hash și un fișier complet este esențială pentru transparență și încredere.
Transmiterea confirmată a vizat versiuni ulterioare/curente din 18 august, nu bytes originali anteriori operațiunii de curățare din 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 a declarat că fișiere complete din versiuni ulterioare/curente au fost trimise pe 18 august prin instrumentul Imunify360 pentru falsuri pozitive către API-ul CloudLinux, împreună cu calea, identificatorul serverului, proprietarul fișierului și o notă.
Documentează ce a fost transmis și corectează înțelegerea anterioară a clientului potrivit căreia erau implicate doar hashuri.
Întrebările privind accesul, retenția ulterioară, copiile, derivatele și lanțul complet de custodie rămân aspecte separate.
O conversație de escaladare vizibilă anterior clientului a încetat să mai apară în istoricul utilizatorului, în timp ce conversații mai vechi au rămas vizibile.
Conversația dispărută conține o parte din dosarul escaladării tehnice și a determinat solicitări de conservare și explicații.
Cauza rămâne nerezolvată, iar dosarul nu afirmă că Hostinger a eliminat conversația pentru a ascunde dovezi.
Escaladarea formală a introdus afirmațiile tehnice contradictorii, întrebările privind producerea înregistrărilor și solicitările de conservare într-un canal de reclamație documentat.
Stabilește ce i se solicita Hostinger să clarifice înainte de revizuirea internă finală.
O reclamație consemnează solicitări și susțineri; fiecare punct factual depinde în continuare de probele care îl susțin.
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 a închis revizuirea internă, a menținut poziția privind eliminarea bazată pe categorie, a documentat mai multe corecții formale, a confirmat transmiterea fișierelor complete către CloudLinux, a enumerat câmpuri importante absente din tabelul de evenimente păstrat și a recunoscut deficiențe în gestionare.
Este cea mai cuprinzătoare poziție Hostinger asupra dosarului din august înainte de repetarea incidentului din septembrie.
Revizuirea finală nu șterge afirmațiile anterioare. Atât afirmațiile inițiale, cât și corecțiile ulterioare rămân parte din cronologie.
Vizualizarea detaliată, redactată pentru publicare, consemnează un eveniment manager.php din 10 septembrie ca Malicious, cu acțiunea Removed. Calea sensibilă a contului este ascunsă în copia publică.
Stabilește că aceeași clasă de problemă distructivă s-a repetat după ce Hostinger își închisese revizuirea internă a disputei din august.
Interfața afișată consemnează clasificarea și acțiunea; backupurile înainte și după eveniment stabilesc separat limita stării fișierului.
Captura publică identifică punctul de recuperare Hostinger din 10 septembrie, 07:09. Dovezile extrase din backup, verificate separat de captură, păstrează fișierul manager.php afectat la 548.265 bytes; un backup independent din aceeași zi păstrează același fișier byte-for-byte.
Oferă o stare pre-eveniment coroborată independent înainte de noua eliminare efectuată de scanner.
Captura stabilește punctul de recuperare; afirmația privind fișierul de 548.265 bytes provine din conținutul backupului extras și verificat, nu din text vizibil în captură.
Captura publică identifică punctul de recuperare Hostinger din 11 septembrie, 07:11. Dovezile extrase din backupul ulterior evenimentului, verificate separat de captură, păstrează aceeași locație a fișierului manager.php afectat la 0 bytes; fișierul activ era de asemenea 0 bytes când incidentul a fost observat.
Împreună cu H-014 și H-013, creează o limită documentară clară între starea pre-eveniment, evenimentul scannerului și starea post-eveniment.
Captura stabilește punctul de recuperare; afirmația privind starea de 0 bytes provine din conținutul backupului extras și verificat și din dovada separată privind starea live.
Înregistrarea a expus calea exactă, un hash înregistrat, dimensiunea de 0 bytes, clasificarea malicious, statusul quarantined, marcajul temporal de carantină, marcajul temporal de audit și un câmp cleanup timestamp cu valoarea null.
Înregistrarea furnizează metadate din sistemul intern, dar evidențiază și un gol semantic pe care suportul nu l-a putut rezolva.
Suportul nu a putut stabili dacă hashul și dimensiunea de 0 bytes descriu același obiect sau aceeași etapă. O corelație independentă de hash, sensibilă strategic, este păstrată momentan în afara dosarului public.
Suportul uman a declarat că cererea explicită de conservare și măsură de păstrare pentru evenimentul din septembrie fusese transmisă și înregistrată în reclamația #137820 la ora 13:04 indicată de Hostinger.
Stabilește că o cerere explicită de conservare a fost introdusă în dosarul reclamației.
Înregistrarea unei cereri nu este echivalentă cu confirmarea aplicării efective a unei măsuri de păstrare.
La 14:47 CEST, suportul uman a declarat că Hostinger nu confirmase încă aplicarea efectivă a măsurii de păstrare.
Separă cererea înregistrată de implementarea efectivă a conservării.
Acesta a fost un status intermediar, completat ulterior prin alte afirmații ale suportului uman din 11 septembrie, inclusiv detalii care se contrazic parțial între ele.
Un agent uman a declarat la 17:02 CEST că instrucțiunea explicită pentru prevenirea expirării sau ștergerii nu fusese încă trimisă.
Afirmația este relevantă deoarece același agent a furnizat ulterior o oră de trimitere anterioară acestui mesaj.
Dosarul public păstrează afirmația fără a deduce motivul pentru care cronologia ulterioară intră în conflict cu ea.
La 17:33 CEST, agentul a declarat că instrucțiunea de non-expirare fusese trimisă la 14:35 UTC, adică 16:35 CEST. Ora de trimitere indicată este anterioară mesajului de la 17:02 care spunea că instrucțiunea nu fusese încă trimisă.
Cele două afirmații ale suportului uman creează un conflict de cronologie procedurală care rămâne parte din dosarul de conservare.
Dosarul nu deduce intenția și nu alege o explicație nedocumentată pentru conflict.
Agentul încă nu putea confirma aplicarea efectivă a măsurii de păstrare, un identificator intern al măsurii de păstrare sau retenția extinsă pentru vreun obiect original sau de carantină păstrat.
Acesta este cel mai recent status de conservare susținut de materialul din arhiva furnizată pentru publicare.
Nu stabilește că dovezile au fost distruse sau că conservarea a fost refuzată. Stabilește că aplicarea efectivă a măsurii de păstrare rămânea neconfirmată la acel moment.
Cererea din 19 august a solicitat explicit Hostinger să păstreze înregistrarea completă a conversației, dosarul GLB-247793, logurile interne asociate scannerului, Event ID-urile, legăturile interne de escaladare și înregistrările privind afirmațiile contestate despre presupusa scanare Engineering/manuală din 14 august. Răspunsul automat a rutat în schimb mesajul către ticketul fără legătură #125522, după care o corecție a cerut Hostinger să nu unească sau redirecționeze cazul și să înregistreze cererea de păstrare sub GLB-247793.
Stabilește o cerere explicită de păstrare privind disputa scannerului înainte de datele de 21-22 august la care Hostinger a plasat ulterior expirarea bytes-ilor originali din carantină și documentează o eroare de rutare chiar în timpul solicitării de păstrare.
Formularea din 19 august nu numea explicit obiectul original din carantină sau bytes-ii anteriori operațiunii de curățare. Dosarul susține astfel o întrebare de cronologie și întindere a cererii, nu afirmația că Hostinger confirmase deja o măsură tehnică de păstrare pentru acei bytes originali.
Hostinger a declarat că reclamația #137820 era legată de GLB-247793, nu urma să fie redirecționată către un ticket fără legătură, era analizată de un membru calificat al echipei și că nu urma să fie inițiată nicio acțiune a scannerului împotriva celor două fișiere contestate cât timp revizuirea era în desfășurare.
Afirmația delimitează exact protecția temporară: privea cele două fișiere contestate și era valabilă doar pe durata revizuirii respective.
Nu era un allowlist permanent, o excepție la nivelul platformei sau o garanție pentru implementări viitoare ori versiuni ulterioare.
Hostinger a declarat că cele patru înregistrări de eveniment și cele două înregistrări de scanare erau supuse unei perioade standard de păstrare de 30 de zile și că fuseseră luate măsuri pentru păstrarea lor după 6 septembrie. Separat, a spus că bytes-ii originali anteriori operațiunii de curățare fuseseră șterși automat în 21-22 august în baza unei politici de carantină de 14 zile. Același răspuns a recunoscut că gestionarea cazului a fost sub standardul la care clientul era îndreptățit să se aștepte.
Distincția este esențială deoarece păstrarea unei înregistrări de eveniment nu este același lucru cu păstrarea bytes-ilor originali ai fișierului din carantină.
Răspunsul nu rezolvă conflictul dintre cererea de păstrare documentată din 19 august și afirmațiile ulterioare despre momentul în care Hostinger a considerat că solicitarea de păstrare fusese primită pentru obiectele originale din carantină.
Hostinger a confirmat că evenimentele 1028417-1028420 au fost generate de Imunify printr-un rescan după actualizarea unei semnături, nu de jobul orar de rutină. A declarat și că clasificarea corectă era una categorică, bazată pe funcționalitatea unui manager de fișiere PHP independent, și că nu deținea o înregistrare specifică celor două fișiere privind acces neautentificat, ocolirea autentificării, exploatare efectivă, compromiterea contului sau acces terț.
Aceasta restrânge atât mecanismul declanșator, cât și baza tehnică pe care Hostinger s-a sprijinit în final.
Poziția bazată pe categorie nu stabilește singură că fișierul era lipsit de risc în orice context de execuție și nu este echivalentă cu o constatare specifică fișierului privind un payload ascuns.
Hostinger a declarat că întregul conținut al versiunilor ulterioare/curente ale fișierelor Tyrus și Site B a fost transmis prin instrumentul Imunify360 către API-ul CloudLinux în 18 august la 08:26:14 UTC și 08:27:01 UTC. Fiecare trimitere includea calea fișierului, identificatorul serverului, proprietarul fișierului, o notă și conținutul complet. Hostinger a spus și că nu exista nicio înregistrare a unei trimiteri către CloudLinux în 8 august și că solicitase CloudLinux informații privind păstrarea/ștergerea copiilor.
Corectează descrierea anterioară limitată la hashuri și identifică exact ce spune Hostinger că a fost transmis din sistemul său, când și prin ce instrument.
Arhiva furnizată pentru publicare nu conține un răspuns ulterior CloudLinux care să clarifice păstrarea, ștergerea, copiile sau derivatele în aval. Versiunile transmise erau fișiere ulterioare/curente, nu obiectele originale anterioare operațiunii de curățare din 7 august.
Hostinger a identificat Imunify360 Detect Admin Tools drept funcția relevantă, a descris clasificarea ca fiind bazată pe categorie și funcționalitate, a declarat că initiator: root reprezenta procesul automat al scannerului, a confirmat cause: rescan și a enumerat câmpurile inexistente în tabelul de evenimente, inclusiv dimensiunea/hashul original, versiunea exactă a regulii, identificatorul componentei scannerului, ID-ul obiectului de carantină și poziția byte-ului sau regiunii care a corespuns detectării. Aceeași revizuire finală a declarat că nu putea fi găsită nicio scanare Engineering, niciun audit, comandă sau job din 14 august.
Este cea mai specifică descriere Hostinger a înregistrării păstrate pentru evenimentul din august și a bazei de politică invocate în determinarea finală.
Absența câmpurilor din acest tabel nu dovedește că niciun alt sistem nu le-a deținut vreodată; stabilește ceea ce Hostinger a spus că nu fusese înregistrat în acest tabel de evenimente păstrat.
Revizuirea nu a găsit indicii statice că versiunea ulterioară/curentă păstrată a Tyrus manager.php ar fi un backdoor/dropper PHP ascuns sau ar conține un payload malițios ascuns. În același timp, a documentat capabilități legitime de administrare cu privilegii ridicate și probleme reale de securitate. Detaliile care ar putea facilita exploatarea sunt omise intenționat din dosarul public.
Susține o distincție precisă între constatări privind malware ascuns și funcționalitate administrativă legitimă cu dublă utilizare, fără a sugera că software-ul era lipsit de probleme de securitate.
Este o revizuire statică a codului unei versiuni ulterioare/curente păstrate, nu o certificare din partea furnizorului motorului antimalware și nu o examinare a bytes-ilor originali anteriori curățării din 7 august, a mediului de execuție sau a tuturor fișierelor auxiliare. Constatările de implementare sensibile din punct de vedere al securității rămân în pachetul privat de dovezi.
You can be confident that the details provided are accurate.
Suportul Hostinger a spus că informațiile tehnice precedente fuseseră furnizate direct de un membru al echipei Senior Technical, descris ca făcând parte din structura de management superior din acea zonă, și l-a asigurat explicit pe client că detaliile erau exacte.
Părți importante ale versiunii tehnice din acea perioadă au fost corectate sau retrase ulterior, inclusiv identitatea scannerului, presupusa scanare Engineering/manuală din 14 august și baza formulărilor despre backdoor/dropper.
Proba stabilește ce a prezentat Hostinger la acel moment despre sursa și fiabilitatea informațiilor. Nu stabilește motivul pentru care corecțiile ulterioare au devenit necesare.
The scanner does not generate an isolated backup prior to cleanup, so account backups or external backups are required for restoration.
Suportul a explicat operațiunea distructivă ca trunchiere imediată la 0 bytes și a spus că scannerul nu genera un backup izolat înainte de curățare.
Hostinger a oferit ulterior o explicație mai precisă cu două obiecte: locația live nu avea un backup în acel loc, dar un subsistem separat de carantină Imunify păstra bytes-ii originali timp de 14 zile.
Proba consemnează explicația oferită clientului în 8 august. Nu inspectează independent subsistemul intern de carantină.
The live file was truncated to 0 bytes at the moment of cleanup, with no backup created at that location. Separately, Imunify's quarantine subsystem held a copy of the original bytes for a fixed 14-day window.
Hostinger a spus că explicațiile anterioare nu diferențiaseră suficient două obiecte distincte: fișierul live vizibil clientului fusese trunchiat la 0 bytes, iar o copie separată din carantina Imunify păstrase bytes-ii originali pentru o perioadă fixă de 14 zile.
Clarifică material explicația inițială despre lipsa unui backup izolat și stabilește modelul de păstrare pe care Hostinger s-a bazat în poziția finală.
Obiectele originale din carantină expiraseră deja la datele indicate de Hostinger, astfel încât dosarul public nu poate inspecta independent acei bytes originali.
Earlier communications that described your files as "confirmed backdoors" or "dropper payloads" were inaccurate in that they implied a file-specific malicious code finding. We acknowledge that the earlier characterizations were misleading and we apologize for the confusion they caused.
Hostinger a corectat explicit implicația anterioară privind o constatare de cod malițios specifică fișierelor și a spus că poziția corectă era o clasificare categorică. A recunoscut și că formulările anterioare au fost înșelătoare.
Este mai mult decât o reinterpretare ulterioară: Hostinger a folosit chiar termenii inexact și înșelător pentru formulările anterioare despre backdoor/dropper.
Hostinger a continuat să mențină clasificarea bazată pe categorie și poziția contractuală după corectarea formulărilor anterioare despre cod malițios specific fișierelor.
Hostinger a spus că numele domeniului folosit în notificarea din 13 august se referea la eticheta domeniului principal al planului de hosting, nu la identificarea celor două locații de fișiere afectate.
Păstrează explicația ulterioară Hostinger pentru neconcordanța vizibilă clientului fără a publica numele domeniului privat.
Explicația este o afirmație ulterioară Hostinger. Arhiva furnizată nu reconstruiește independent mecanismul de generare a notificării care a selectat acea etichetă.