PARTEA II: EXPLICAȚIA TEHNICĂ S-A SCHIMBAT
Dosarul din august până la 7 septembrie: explicații tehnice schimbate, corecții formale, dezvăluirea privind CloudLinux, înregistrări lipsă, gestionarea Compliance și analiza internă finală Hostinger.
Partea II acoperă perioada de după publicarea din 8 august până la analiza internă finală Hostinger din 7 septembrie. Importanța acestei perioade stă în modul în care explicația tehnică s-a schimbat pe măsură ce reclamația a trecut de la suportul obișnuit la escaladare tehnică și analiză Compliance.
De la gestionarea ca fals pozitiv la clasificarea bazată pe categorie
Dosarul inițial de suport a tratat incidentul într-un mod care a dus la prezentarea unui allowlist. Comunicările ulterioare au trecut la formulări despre backdoor confirmat și dropper. Până la analiza internă finală, poziția menținută de Hostinger era din nou diferită: fișierele erau clasificate pe baza categoriei și funcționalității ca instrumente administrative, fără o înregistrare specifică fișierelor privind authentication bypass, exploatare, compromitere, acces terț sau payload ascuns.
Allowlist-ul care nu a fost activat niciodată
Pe 8 august, suportul a prezentat că hashurile și căile relevante fuseseră trimise pentru gestionarea unui allowlist persistent. Hostinger a confirmat ulterior că niciun allowlist nu a fost activat vreodată și a caracterizat oferta și revenirea asupra ei drept un eșec de gestionare. Afirmația inițială rămâne vizibilă în dosar deoarece face parte din cronologia transmisă clientului.
Versiunea privind scanarea din 14 august a fost retrasă
Comunicările suportului au descris o verificare manuală sau Engineering din 14 august. Analizele ulterioare Hostinger au corectat progresiv această versiune. Analiza internă finală din 7 septembrie a afirmat că nu poate fi găsită nicio înregistrare privind o scanare Engineering, un audit, o comandă sau un job care să corespundă prezentării anterioare. Dosarul tratează astfel versiunea inițială despre scanare ca afirmație Hostinger retrasă, nu ca eveniment stabilit.
Dezvăluirea privind CloudLinux a schimbat amploarea problemei de transparență
Hostinger a corectat ulterior prezentarea anterioară centrată doar pe hashuri și a confirmat că întregul conținut al unor versiuni ulterioare/curente ale fișierelor fusese transmis pe 18 august prin instrumentul Imunify360 pentru falsuri pozitive către API-ul CloudLinux, împreună cu metadatele asociate. Aceste transmiteri nu au reprezentat bytes originali de dinaintea cleanup-ului din 7 august. Distincția dintre copiile ulterioare/curente și obiectele originale eliminate este păstrată în întregul dosar.
Golurile din înregistrări au rămas importante
Analiza finală Hostinger a confirmat că tabelul de evenimente din august păstrat de companie nu conținea mai multe câmpuri solicitate repetat în timpul disputei, inclusiv dimensiunea și hashul original, versiunea exactă a regulii, componenta scannerului și byte-ul sau regiunea care a corespuns. Hostinger a menținut și poziția că bytes originali aflați în carantină expiraseră conform procesului normal de retenție și că nu mai exista din partea sa o copie secundară, o imagine forensic sau un digest derivat al acelor bytes originali.
Conversația dispărută din istoricul clientului rămâne nerezolvată
O conversație de escaladare vizibilă anterior clientului a încetat să mai apară în istoricul Hostinger al utilizatorului, în timp ce conversații mai vechi au rămas vizibile. Analiza finală a discutat înregistrarea internă GLB, care reprezintă o problemă diferită. Dosarul păstrează astfel dispariția conversației vizibile clientului ca nerezolvată și nu atribuie o intenție pe care documentele nu o stabilesc.
Analiza internă finală Hostinger
Pe 7 septembrie, Hostinger a declarat închisă analiza internă. A menținut poziția că eliminarea din august a fost corectă și permisă contractual, a furnizat identificatori de eveniment și scanare, a confirmat că unele câmpuri importante solicitate nu fuseseră capturate, a formalizat mai multe corecții, a confirmat transmiterile de fișiere complete către CloudLinux și a recunoscut că afirmațiile contradictorii și gestionarea allowlist-ului nu ar fi trebuit să ajungă la client în forma în care au ajuns.