T-01
Eliminările inițiale ale scannerului malware
Două fișiere manager.php de pe implementări separate au fost clasificate și supuse unui cleanup distructiv. Rezultatul vizibil pentru client a fost un fișier de 0 bytes.
TRACE / DOSAR SPECIAL 003
CRONOLOGIA COMPLETĂ
Cronologia completă a disputei privind scannerul malware Hostinger, de la incidentul din august până la recurența din septembrie și dosarul de conservare.
T-02
Allowlist-ul a fost prezentat ca fiind în curs de procesare
Suportul Hostinger a afirmat că hashurile și căile fuseseră trimise echipei malware pentru o intrare persistentă în allowlist și că solicitările erau procesate. Ulterior, Hostinger a confirmat că niciun allowlist nu a fost activat vreodată.
CORECTAT ULTERIORT-03
Au apărut explicații despre backdoor, dropper și scanare manuală
Comunicările ulterioare ale suportului au folosit formulări despre backdoor confirmat și dropper și au descris o scanare Engineering sau manuală din 14 august. Hostinger a retras în final versiunea privind scanarea din 14 august și a corectat atribuirea scannerului din Monarx în Imunify.
RETRAS ULTERIORT-04
Fișiere complete, din versiuni ulterioare/curente, au fost trimise către CloudLinux
Hostinger a confirmat ulterior că întregul conținut al unor versiuni ulterioare/curente ale fișierelor, nu doar valorile hash, a fost trimis prin instrumentul Imunify360 de raportare a falsurilor pozitive către API-ul CloudLinux, împreună cu metadatele asociate.
CORECTAT ULTERIORT-05
Escaladare formală către Compliance
Disputa a fost escaladată formal, cu solicitări privind înregistrările tehnice, conservarea, conversația de escaladare dispărută din istoricul vizibil al clientului și explicațiile contradictorii primite deja.
T-06
Hostinger a confirmat că niciun allowlist nu fusese activat
Un răspuns punct cu punct a furnizat patru event IDs și scan IDs, a descris cleanup-ul ca trunchiere la 0 bytes, a menținut o clasificare bazată pe categorie și a recunoscut că allowlist-ul oferit nu fusese activat niciodată. Hostinger a descris oferta și revenirea asupra ei drept un eșec de gestionare.
T-07
Corecțiile tehnice au devenit explicite
Hostinger a confirmat transmiterea fișierelor complete către CloudLinux, a retras atribuirea către Monarx, a afirmat că nu poate fi găsită o scanare manuală completă Imunify360 din 14 august, a corectat descrierea anterioară referitoare doar la hashuri și a retras comparația specifică de dimensiuni.
CORECTAT ULTERIORT-08
Hostinger a emis analiza internă finală
Hostinger a închis analiza internă și a menținut poziția că eliminările din august au fost corecte și permise contractual. Același răspuns a consemnat formal mai multe corecții, a confirmat transmiterea fișierelor complete către CloudLinux, a identificat câmpuri importante care nu fuseseră capturate în înregistrările evenimentelor și a recunoscut că afirmațiile contradictorii nu ar fi trebuit să ajungă la client.
T-09
A avut loc o nouă eliminare a manager.php după analiza finală
O nouă implementare a fișierului manager.php din rădăcina Jurist apare în interfața malware Hostinger ca Malicious și Removed. Un backup Hostinger anterior evenimentului și un backup independent din aceeași zi păstrează fișierul complet, iar un backup Hostinger ulterior evenimentului păstrează aceeași cale la 0 bytes.
T-10
Suportul a expus un hash și o dimensiune înregistrată de 0 bytes fără a putea explica semantica acelor câmpuri
Înregistrarea accesibilă suportului a expus calea, un hash înregistrat, dimensiunea de 0 bytes, clasificarea malicious, statusul quarantined și timestampuri. Suportul nu a putut stabili dacă hashul și dimensiunea descriu același obiect sau aceeași etapă a procesului de carantină și eliminare.
T-11
Cererea de conservare a fost înregistrată; aplicarea hold-ului nu a fost confirmată
Suportul uman a afirmat că cererea explicită de conservare și retention hold fusese înregistrată în reclamația #137820 la 13:04. La 14:47, suportul a spus că Hostinger nu confirmase aplicarea efectivă a hold-ului de conservare.
T-12
Afirmațiile ulterioare despre conservare se contrazic, iar aplicarea efectivă a hold-ului rămâne în așteptare
La 17:02 un agent uman a spus că instrucțiunea explicită de non-expirare nu fusese încă trimisă. La 17:33 același agent a spus că fusese trimisă la 14:35 UTC, adică 16:35 CEST. La 17:40 agentul încă nu putea confirma aplicarea efectivă a hold-ului, un identificator intern al hold-ului sau retenția extinsă a vreunui obiect original sau de carantină păstrat.
RĂMÂNE NEREZOLVAT