PARTEA III: PROBLEMA S-A REPETAT
Recurența din 10 septembrie, backupurile păstrate înainte și după eveniment, înregistrările scannerului Hostinger și cronologia conservării din 11 septembrie.
Recurența din septembrie este documentată separat deoarece a avut loc după ce Hostinger emisese deja analiza internă finală. Cea mai puternică parte a acestui dosar este delimitarea independentă înainte și după eveniment în jurul noii acțiuni a scannerului.
O stare clară înainte de eveniment
Un backup Hostinger pregătit din 10 septembrie, 07:09, păstrează manager.php din rădăcina Jurist la 548.265 bytes. Un backup independent creat în aceeași zi păstrează exact același fișier byte-for-byte. Cele două surse independente stabilesc starea fișierului înainte de noul eveniment malware fără a depinde de o reconstrucție bazată pe afirmațiile suportului Hostinger.
Evenimentul scannerului
Interfața malware Hostinger consemnează un nou eveniment pentru manager.php ca Malicious, cu acțiunea Removed. Data din interfață și timestampurile de backend expuse ulterior de suport sunt păstrate exact așa cum au fost înregistrate, deoarece sistemele pot reprezenta etape sau fusuri orare diferite. Dosarul nu le forțează tăcut într-un singur timestamp.
Starea de după eveniment
Un backup Hostinger pregătit din 11 septembrie, 07:11, păstrează aceeași cale manager.php la 0 bytes. Fișierul live era de asemenea 0 bytes când incidentul a fost observat. Succesiunea documentată conține astfel un fișier complet înainte de eveniment, evenimentul scannerului și un backup Hostinger ulterior al aceleiași căi la 0 bytes.
Suportul a expus metadate de backend, dar nu a putut explica semantica acestora
Pe 11 septembrie, o înregistrare accesibilă suportului a expus calea exactă, un hash înregistrat, o dimensiune înregistrată de 0 bytes, clasificarea malicious, statusul quarantined, un timestamp de carantină, un timestamp de audit și un cleanup timestamp null. Suportul nu a putut stabili dacă hashul înregistrat și dimensiunea de 0 bytes descriau același obiect sau aceeași etapă a ciclului de viață. Dosarul public păstrează această incertitudine în loc să furnizeze o explicație speculativă.
Conservarea a devenit o nouă problemă pe 11 septembrie
Suportul uman a confirmat că cererea explicită de conservare și retention hold fusese înregistrată în reclamația #137820. Afirmațiile ulterioare disting acea cerere înregistrată de aplicarea efectivă a unui hold. La 17:40 CEST, suportul Hostinger încă nu confirmase aplicarea efectivă a hold-ului, un identificator intern al acestuia sau retenția extinsă a vreunui obiect original ori de carantină păstrat.
Cronologia conservării conține un conflict care rămâne neexplicat
La 17:02 CEST, 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. Ora de trimitere indicată este astfel anterioară mesajului care spunea că instrucțiunea nu fusese încă trimisă. Ambele afirmații sunt păstrate exact cum au fost furnizate. Dosarul nu deduce intenția și nu inventează un motiv pentru inconsistență.
Statusul procedural s-a schimbat și el după recurență
Hostinger a descris răspunsul din 7 septembrie drept concluzia analizei interne. După noua eliminare din 10 septembrie, suportul a spus pe 11 septembrie că dosarul era încă deschis și analizat de o echipă tehnică specializată. Afirmațiile pot privi etape procedurale diferite, astfel încât dosarul public le păstrează pe ambele fără a le prezenta ca pe un singur status confirmat.