Site-uri false pentru zero-day Chrome și Windows
Pe 21 septembrie 2026, Volexity a publicat a doua parte a analizei despre lanțul de exploituri folosit la începutul lunii împotriva Chrome și Windows. Prima parte, din 9 septembrie, documenta vulnerabilitățile. Partea a doua răspunde la întrebarea care lipsea: cum ajungeau victimele acolo. Răspunsul este site-uri false care imitau publicații și organizații reale.
Cele trei vulnerabilități folosite sunt CVE-2026-85046 și CVE-2026-87491 în Chrome și CVE-2026-85880 în Windows. Toate trei erau zero-day în momentul utilizării, pe 3 și 4 septembrie, adică erau exploatate înainte să existe corecții. Astăzi toate trei se află în catalogul CISA KEV, iar două dintre termenele federale cad chiar acum: 22 septembrie pentru CVE-2026-85880 și 23 septembrie pentru CVE-2026-87491.
Site-uri care arătau exact ca originalul
Conform Volexity, victimele ajungeau pe domenii typosquat prin emailuri de phishing. Trei sunt numite în raport: chinadigitaltimes[.]top, care imita publicația China Digital Times, americanprgoress[.]top, care imita Center for American Progress, și thecovnresation[.]com, care imita The Conversation și era folosit drept infrastructură de comandă și control.
Le enumerăm defanged pentru că exact asta îi trebuie unui apărător: șiruri de căutat în logurile de proxy, DNS și endpoint. Nu sunt secrete; sunt publicate de cercetător tocmai ca să poată fi căutate.
Mecanismul de pe site-ul care imita Center for American Progress merită înțeles, pentru că explică de ce nimeni nu a observat nimic. Pagina încărca conținut legitim, deci arăta corect pentru un om care o deschidea. Separat, includea un iframe ascuns care executa config.html, iar acela livra lanțul de exploituri. Payload-ul final, un fișier numit chrome_cleanup.exe, era descărcat de pe același site fals.
Cu alte cuvinte, verificarea umană obișnuită — „arată ca site-ul pe care îl citesc de ani de zile” — nu avea cum să funcționeze. Conținutul chiar era cel real. Diferența era în domeniu și în ce se încărca în fundal.
Un al treilea actor, și ce înseamnă asta
Volexity atribuie această activitate unui actor de amenințare chinez pe care îl urmărește sub numele UTA0565 și precizează că este un al treilea actor chinez, distinct de cei doi documentați în postarea din 9 septembrie. Atribuirea aparține cercetătorului; o raportăm ca atare, nu ca pe un fapt stabilit independent.
Detaliul care contează operațional nu este numele actorului, ci numărul. Același lanț de zero-day a fost folosit, în aceeași fereastră, de trei grupuri diferite. Asta schimbă modul în care citești o astfel de știre: nu este un adversar unic cu o capacitate rară, ci o capacitate care circulă între mai multe grupuri înainte să existe patch.
Țintele descrise sunt entități guvernamentale din Asia, organizații media și ONG-uri. Una dintre momeli viza subiectul activistei din Hong Kong Chow Hang-tung; alta se prezenta drept Center for American Progress. Este un profil de țintire care privește jurnaliștii, cercetătorii și organizațiile civice mai mult decât o companie obișnuită — dar mecanismul de livrare nu are nimic specific acelui profil.
Volexity își declară singură limita, iar merită citată: activitatea raportată până acum reflectă observațiile a doar două organizații, iar amploarea și impactul real sunt probabil mult mai mari. De asemenea, cercetătorii precizează că nu au putut analiza complet unul dintre site-uri, pentru că cel care imita China Digital Times nu mai era disponibil la momentul analizei.
Unde sunt astăzi cele trei CVE-uri
Am verificat direct catalogul KEV, versiunea 2026.09.21. CVE-2026-85046, în Chromium V8, a fost adăugat pe 4 septembrie, cu termen 18 septembrie. CVE-2026-87491, tot în Chromium V8, a fost adăugat pe 9 septembrie, cu termen 23 septembrie. CVE-2026-85880, în Microsoft Windows, a fost adăugat pe 8 septembrie, cu termen 22 septembrie. Toate trei înregistrează utilizarea în campanii ransomware ca fiind necunoscută.
Termenele obligă agențiile federale civile americane sub Binding Operational Directive 26-04 și nu sunt o obligație legală pentru o organizație din România. Sunt însă un reper util, iar faptul că două dintre ele cad exact în aceste zile face verificarea oportună, nu teoretică.
Dacă ai citit deja articolele noastre despre CVE-2026-85046 și CVE-2026-87491, partea de patch îți este familiară. Ce adaugă raportul de acum nu este o nouă sarcină de actualizare, ci o listă de lucruri de căutat în urmă, pentru fereastra 3–4 septembrie, când corecțiile încă nu existau.
Ce verifici, concret
- ▸Confirmă nivelul de build pentru Chrome și pentru Windows pe toată flota, nu doar pe serverele gestionate. Browserul este activul vizat aici, iar el rulează pe laptopuri, inclusiv pe cele ale oamenilor care citesc mult presă și rapoarte.
- ▸Caută în logurile de DNS, proxy și firewall cele trei domenii publicate de Volexity, pentru perioada care începe cel puțin la 3 septembrie. Notează explicit cât de departe în urmă ai putut căuta: dacă retenția ta este de șapte zile, răspunsul tău despre 3 septembrie este „nu știu”, iar asta trebuie scris ca atare.
- ▸Caută pe endpointuri fișierul chrome_cleanup.exe și execuții pornite din directoare de descărcare. Numele este ales ca să pară un utilitar legitim de curățare a browserului.
- ▸Verifică dacă ai vizibilitate asupra domeniilor typosquat în general. Publicațiile și think tank-urile pe care oamenii tăi chiar le citesc sunt o categorie de imitat, iar o alertă pe domenii nou înregistrate asemănătoare cu ele este un control care se poate pune înainte de următoarea campanie.
- ▸Pentru persoanele cu profil expus — jurnaliști, cercetători, oameni care lucrează pe subiecte sensibile — tratează browserul ca pe o suprafață care are nevoie de actualizare prioritară și, unde este disponibil, de modurile de protecție suplimentară oferite de sistemul de operare și de browser.
- ▸Dacă găsești ceva, oprește-te înainte de a concluziona. Un DNS lookup către un domeniu typosquat nu este o compromitere; este un indiciu care cere corelare cu execuția pe endpoint și cu traficul ulterior.
De ce „mind the patch gap” este o problemă de proces, nu de viteză
Titlul ales de Volexity descrie intervalul dintre momentul în care o vulnerabilitate este exploatată și momentul în care există o corecție. În acest caz intervalul a fost real: exploatarea pe 3–4 septembrie, corecțiile ulterior, intrările KEV între 4 și 9 septembrie.
Un program de patching, oricât de rapid, nu acoperă acel interval prin definiție. Ce îl acoperă parțial sunt controale care nu depind de existența unei corecții: reducerea suprafeței expuse, segmentarea, detecția pe comportament și, foarte concret în acest caz, capacitatea de a căuta în urmă după ce apare raportul.
Aceasta este și concluzia practică pentru inventar. Valoarea unei liste de active nu se vede în ziua în care aplici patch-ul, ci în ziua în care cineva publică trei domenii și o dată, iar tu trebuie să răspunzi în câteva ore la întrebarea „ne-a atins?”. Dacă nu știi ce browsere rulează unde și ce loguri mai ai din urmă cu trei săptămâni, întrebarea rămâne fără răspuns indiferent cât de repede actualizezi.
O notă de onestitate: raportul Volexity nu conține recomandări defensive publice. Cercetătorii oferă evaluarea țintirii și pun indicatorii la dispoziția clienților serviciului lor de threat intelligence. Verificările de mai sus sunt derivate de noi din mecanismul descris și din datele KEV, nu preluate din raport.
Dovada minimă pentru închidere
Awarely Monitor ajută la urmărirea contextului CVE și KEV, la atribuirea responsabililor și la păstrarea dovezilor deciziilor până la închidere. Nu inventariază browserele din flotă, nu citește logurile tale de DNS sau proxy, nu detectează domenii typosquat și nu analizează endpointuri. Verificarea versiunilor, căutarea în loguri și investigația rămân în uneltele tale de management al dispozitivelor și în procesul de răspuns la incident.
- ▸Nivelurile de build Chrome și Windows pe flotă, cu numărul de dispozitive rămase sub versiunile corectate și planul pentru ele.
- ▸Domeniul căutării în loguri: ce surse ai interogat, ce perioadă acoperă retenția, ce domenii și artefacte ai căutat și rezultatul.
- ▸Limitele explicite ale investigației, inclusiv perioadele pentru care nu mai ai date.
- ▸Decizia pentru utilizatorii cu profil expus: ce protecții suplimentare au fost activate, pentru cine și când.
- ▸Dacă au apărut indicii: dovezile păstrate, corelarea făcută și concluzia, separată clar de ipoteză.
- ▸Legătura dintre cele trei CVE-uri, intrările KEV, activele afectate, responsabil și dovezile păstrate până la închidere.
Întrebarea nu e doar dacă ai actualizat
Folosește contextul CVE și KEV din Awarely Monitor pentru prioritate și responsabil, apoi verifică în mediul tău nivelurile de build și ce loguri mai ai din fereastra în care nu exista patch.
