Știri
Știri din categoria Securitate cibernetică
Botnetul Aisuru a lansat un atac DDoS de 31,4 Tbps, stabilind un nou record mondial, potrivit BleepingComputer. Acest atac masiv, parte a campaniei denumite „The Night Before Christmas”, a fost detectat și atenuat de Cloudflare pe 19 decembrie 2025.
Aisuru, cunoscut și sub numele de Kimwolf, a vizat multiple companii, în special din sectorul telecomunicațiilor. Atacul a atins un vârf de 31,4 Tbps și 200 de milioane de cereri pe secundă, fiind cel mai mare atac de acest tip dezvăluit public până acum. Cloudflare a reușit să detecteze și să atenueze automat aceste atacuri hiper-volumetrice, fără a declanșa alerte interne.
„Campania a vizat clienții Cloudflare, precum și infrastructura și tabloul de bord al Cloudflare, cu atacuri DDoS HTTP hiper-volumetrice care au depășit rate de 200 de milioane de cereri pe secundă, alături de atacuri DDoS de nivel 4 care au atins 31,4 terabiți pe secundă, făcându-l cel mai mare atac dezvăluit public vreodată”, afirmă Cloudflare într-un raport.
Campania „The Night Before Christmas” a constat în atacuri care au durat între unul și două minute, majoritatea atingând vârfuri între 1-5 Tbps. Aproximativ 94% dintre atacuri au avut o intensitate cuprinsă între 1-5 miliarde de pachete pe secundă. Botnetul Aisuru și-a obținut puterea din dispozitive IoT și routere compromise, însă sursele atacurilor din această campanie au fost televizoare Android.
Conform raportului Cloudflare pentru trimestrul al patrulea din 2025, numărul atacurilor DDoS a crescut cu 121% față de 2024, ajungând la 47,1 milioane de incidente. În medie, Cloudflare a atenuat 5.376 de atacuri DDoS pe oră în 2025, 73% dintre acestea fiind atacuri la nivel de rețea.
Cele mai vizate industrii au fost furnizorii de servicii de telecomunicații, firmele IT și de servicii, cazinourile și companiile de jocuri. Cele mai multe atacuri au provenit din Bangladesh, Ecuador și Indonezia, cu Argentina urcând pe locul patru, iar Rusia coborând pe locul zece. Atacurile au vizat în principal organizații din China, Hong Kong, Germania, Brazilia și Statele Unite.
Raportul Cloudflare subliniază că peste 71,5% din toate atacurile DDoS HTTP înregistrate provin de la botneturi cunoscute/documentate. Această tendință de creștere a numărului de atacuri DDoS este un semnal de alarmă pentru companiile din întreaga lume, care trebuie să își consolideze măsurile de securitate cibernetică.
Recomandate
Cloudflare vrea să facă certificatele TLS „rezistente la cuantic” disponibile în masă, fără costuri suplimentare și fără penalizări de performanță , printr-o schimbare de arhitectură care ar putea rescrie modul în care web-ul își validează identitatea site-urilor, potrivit Ars Technica . Compania spune că plănuiește să emită certificate TLS „quantum-proof” (concepute să reziste atacurilor posibile cu ajutorul calculatoarelor cuantice), devenind una dintre primele autorități care fac acest pas. Abordarea se bazează pe o platformă open-source care emite atât certificate TLS clasice, cât și o variantă post-cuantică numită „Merkle Tree Certificates”. Cloudflare afirmă că aceste certificate hibride vor fi gratuite atât pentru clienții plătitori, cât și pentru cei neplătitori. De ce contează: schimbarea nu e „un algoritm nou”, ci o reconstrucție a WebPKI Miza este protejarea WebPKI (infrastructura de chei publice a web-ului, care stă la baza autentificării site-urilor și a HTTPS) într-o lume în care semnăturile criptografice clasice ar putea deveni vulnerabile. Cloudflare descrie tranziția ca pe un efort de durată, care implică un număr foarte mare de ingineri și organizații din ecosistem: sisteme de operare, browsere, autorități de certificare și furnizori de infrastructură Internet. Un obstacol major: semnăturile „quantum-proof” ar fi greu de transportat în cererile web și de înregistrat în jurnalele de transparență (mecanisme publice care ajută la detectarea certificatelor false). În plus, articolul notează că o versiune „post-cuantică” a certificatelor X.509 de azi ar crește de aproximativ 40 de ori volumul de date necesar pentru un „TLS handshake” (negocierea inițială a conexiunii securizate), ceea ce ar adăuga costuri de calcul și trafic care „ar strica Internetul așa cum îl știm”. Cum încearcă Cloudflare să evite costul de performanță: Merkle Trees și certificate hibride Soluția prezentată se bazează pe „Merkle Trees” (structuri ierarhice care folosesc funcții hash pentru a verifica volume mari de informații cu o cantitate mică de date). În februarie, Google a anunțat această direcție, iar Google și Cloudflare au testat-o în programe pilot limitate, potrivit materialului. În loc să înlocuiască lanțurile actuale de semnături (considerate vulnerabile la cuantic) cu unele rezistente, dar „prea grele”, modelul folosește dovezi compacte bazate pe Merkle Trees. Ideea este că o autoritate de certificare semnează un singur „tree head” care poate reprezenta milioane de certificate, iar browserul verifică un „landmark” – o dovadă „ușoară” că certificatul se află undeva în arbore. Cloudflare susține că, astfel, volumul de date din handshake ar coborî la circa 40 kilobytes, „aproximativ cât se procesează acum”. Pașii operaționali: achiziția unui root de încredere și integrarea cu logurile de transparență Pentru a accelera adoptarea, Cloudflare spune că va achiziționa un „certificate root” deja de încredere de la CA GlobalSign. Ținta declarată este ca „milioane de site-uri” să poată activa certificate post-cuantice „la o apăsare de buton”, fără costuri suplimentare de performanță. Un alt element important este legarea mai strânsă a emiterii de certificate de „certificate transparency logs” – registre publice append-only (în care se pot adăuga înregistrări, dar nu se pot modifica retroactiv) folosite pentru a detecta certificate emise abuziv. În modelul Merkle Tree Certificates, „logarea” devine parte centrală a emiterii, nu un proces separat. Cloudflare o citează pe inginerul Mari Galicer: „Prin cuplarea emiterii și logării, transparența devine o cerință de funcționare, nu un adaos.” Contextul acestor loguri vine din incidente precum compromiterea DigiNotar din 2011, când au fost create 500 de certificate contrafăcute pentru Google și alte site-uri, unele folosite pentru spionarea utilizatorilor web din Iran, notează articolul. Calendar: când ar putea începe emiterea Cloudflare precizează că nu emite încă aceste certificate și că va mai dura până va începe efectiv, dar își asumă public proiectul și promite actualizări pe măsură ce atinge etape intermediare. Compania se așteaptă să înceapă emiterea în primul trimestru din 2027. În paralel, planul include și utilizarea ACME (Automated Certificate Management Environment), un mecanism open-source pentru emiterea și reînnoirea automată a certificatelor înainte de expirare, precum și un mecanism prin care semnăturile ar putea fi livrate „out-of-band” (pe o cale separată, de exemplu printr-un update de browser) dacă apar probleme tehnice care împiedică obținerea actualizărilor necesare. [...]
Google va condiționa reclamele financiare din SUA și Canada de o verificare suplimentară a autorizării , într-o mișcare care ridică pragul de conformare pentru bănci și alți furnizori legitimi, dar urmărește să reducă impersonarea de brand și fraudele din publicitate, potrivit Google Blog . Măsura extinde programul „ Financial Services Verification ” (verificare pentru servicii financiare) în două piețe nord-americane, pe baza unui mecanism existent de verificare a identității advertiserilor. Google spune că, în SUA și Canada, peste 97% dintre reclamele văzute pe Google provin deja de la advertiseri cu identitatea verificată. Ce se schimbă pentru advertiserii din servicii financiare Pe lângă verificarea identității, noul strat de control introduce o verificare specializată a acreditărilor: advertiserii vor trebui să demonstreze că sunt autorizați de autorități de reglementare relevante sau de registre recunoscute înainte de a putea rula anumite reclame financiare. Obiectivul declarat este să limiteze: impersonarea unor instituții financiare (brand impersonation); accesul actorilor rău intenționați la utilizatori prin reclame. Google indică faptul că programul, în forma sa actuală, protejează aproximativ 2 miliarde de utilizatori de internet în 42 de țări, fiind „cel mai amplu program de acest tip”. Implementare etapizată și rolul registrelor bancare Google afirmă că va adapta implementarea în funcție de particularitățile fiecărei țări, invocând diferențe de reglementare și o introducere în etape („phased implementation”). În SUA, compania spune că lucrează cu American Bankers Association pentru a folosi registrul dedicat al acesteia, astfel încât băncile autorizate să fie verificate înainte ca reclamele să poată rula. În Canada, Google menționează colaborarea cu Canadian Bankers Association în pregătirea lansării. Calendar: țintă de lansare la începutul lui 2027 Google indică un „planned rollout” la începutul lui 2027. Înainte de lansare, compania promite informații specifice pe țări pentru advertiseri, inclusiv: registre acceptate, acreditări necesare, instrucțiuni de înrolare (onboarding). După deschiderea verificării, advertiserii vor fi notificați dacă și când trebuie să parcurgă procesul, iar ghidajul ar urma să fie oferit înainte de începerea aplicării (enforcement) politicii. Context: automatizare și colaborare anti-fraudă Google leagă verificarea „upfront” de sistemele sale de siguranță, menționând că în 2025 Gemini a ajutat la identificarea a peste 99% dintre reclamele care încălcau politicile, înainte ca acestea să fie difuzate. Inițiativa este prezentată și ca parte a unor eforturi mai largi de schimb de informații între tehnologie, finanțe și autorități, inclusiv prin Global Signal Exchange. [...]
Aproximativ 421.000 de e-mailuri atribuite AfD ar fi ajuns online după un atac cibernetic , un incident care ridică riscuri operaționale pentru organizații ce își externalizează infrastructura de găzduire și gestionează volume mari de corespondență internă, potrivit G4Media . Atacul ar fi vizat infrastructura de găzduire a partidului german Alternativa pentru Germania (AfD) și ar fi dus la copierea ilegală a unor mesaje din mai multe conturi de e-mail. Publicația germană Bild susține că aproximativ 421.000 de e-mailuri au apărut online, însă autenticitatea datelor nu a fost confirmată. Un purtător de cuvânt al AfD a confirmat pentru Die Zeit că partidul a fost ținta unui atac cibernetic în septembrie 2026 și că persoane necunoscute au copiat ilegal părți din câteva conturi de e-mail. Acesta a mai spus că majoritatea conturilor vizate nu mai fuseseră folosite de ani de zile și că adresele de e-mail actuale ale conducerii federale nu au fost afectate. Ce se știe despre scurgerea de date și ce rămâne neconfirmat Potrivit informațiilor publicate de Bild, autorii presupusei scurgeri de date afirmă că mesajele provin din zece conturi de e-mail. Printre conturile vizate s-ar afla unul asociat cu Alexander Gauland , fost lider al AfD, precum și un alt cont pe care partidul l-ar fi indicat anterior drept punct de contact pentru sediul său federal. În acest stadiu, nu este clar dacă toate mesajele publicate sunt autentice și nici dacă volumul de date prezentat de autori corespunde realității. Răspunsul AfD și pașii următori Purtătorul de cuvânt al partidului a declarat că atacul a fost detectat și oprit într-un interval scurt de timp, iar ulterior persoanele ale căror conturi au fost vizate au fost informate. Investigația este în curs, iar circumstanțele exacte ale atacului și amploarea scurgerii de date nu au fost stabilite definitiv. Până la clarificarea incidentului, autenticitatea și proveniența tuturor datelor publicate rămân incerte. [...]
Google Play Services ar asocia automat numărul de telefon cu toate conturile Google autentificate pe același dispozitiv, fără notificare , ceea ce poate crea o legătură directă între identități pe care utilizatorii încearcă să le țină separate (personal, serviciu, cont „anonim”), potrivit Android Police . Informația pornește de la o sesizare a unui utilizator pe Reddit, preluată de publicație, potrivit căreia Google Play Services ar „verifica” numerele de telefon de pe telefon și le-ar atașa tuturor conturilor Google conectate pe acel dispozitiv ( Android Police notează că subiectul a fost semnalat și „via Android Authority”). Publicația subliniază că nu ar exista un avertisment sau o solicitare explicită de acord. Miza nu este neapărat că datele „se amestecă” între conturi, ci că același identificator (numărul de telefon) devine comun mai multor conturi. Chiar dacă utilizatorul nu vede conținutul unui cont în altul, această asociere poate funcționa ca un „fir” care leagă conturile între ele și de persoana reală din spatele lor — exact opusul separării pe care o urmăresc mulți utilizatori când folosesc mai multe conturi pe același telefon. Ce poți face dacă vrei să reduci asocierea dintre conturi Android Police descrie câțiva pași care ar putea limita sau corecta situația, deși menționează că procesul „ia ceva timp”: Dezactivarea sincronizării/validării automate a numărului de telefon : în aplicația Setări → Google → Toate serviciile → zona Confidențialitate și securitate → opțiunea Verificarea numărului de telefon (denumirile pot varia ușor în funcție de versiunea Android). Verificarea numerelor salvate în cont : în contul Google → secțiunea Informații personale → Telefon , unde pot apărea numere stocate ce pot fi șterse. Repetarea verificărilor pentru fiecare cont Google folosit pe telefon, dacă obiectivul este separarea lor. Context: semnalări inclusiv pe GrapheneOS Autorul notează că utilizatorul de pe Reddit ar fi întâlnit același comportament și pe un dispozitiv cu GrapheneOS (un sistem orientat spre confidențialitate). Publicația tratează situația ca pe un exemplu de practică „deloc surprinzătoare” în ecosistemul marilor platforme, dar accentul rămâne pe consecința practică: utilizatorii care folosesc mai multe conturi pentru separare ar putea descoperi că acestea sunt totuși conectate prin numărul de telefon. Android Police recomandă, în esență, ca cei interesați să verifice rapid ce numere sunt asociate conturilor lor și să ajusteze setările dacă nu doresc această legare automată. [...]
Un agent AI a semnalat un miner cripto ascuns pe Mac, un caz care arată cum „asistenții” de programare pot deveni un instrument practic de detecție operațională a malware-ului : un dezvoltator care folosea Claude Code pentru a construi o aplicație de monitorizare a temperaturii a primit avertismentul că pe sistem rulează XMRig , potrivit Tom's Hardware . Agentul i-a transmis utilizatorului că a observat „xmrig” consumând „aprox. 1175% CPU, adică în jur de 12 nuclee”, ceea ce a împins temperaturile până la 112 grade, conform articolului. XMRig este un program folosit frecvent pentru minare de criptomonede și, în astfel de scenarii, poate fi rulat fără acordul utilizatorului, ca parte a unei infectări. Dezvoltatorul (menționat ca Redditor „UntilHEX”) a recunoscut că prezența minerului „explică de ce Mac-ul meu a mers ca naiba”, indicând un impact direct asupra performanței și, implicit, asupra utilizării zilnice a sistemului. De ce contează pentru companii și echipe tehnice Cazul subliniază un efect operațional concret: instrumentele AI folosite în dezvoltare pot ajunge să observe anomalii de sistem (procese suspecte, consum neobișnuit de resurse) în timpul lucrului, funcționând ca un „semnal de alarmă” suplimentar, chiar dacă nu sunt soluții dedicate de securitate. În același timp, episodul arată cât de vizibile pot fi simptomele unui miner cripto pe un laptop de lucru: consum extrem de ridicat de CPU (în acest caz, „1175%”, echivalentul a ~12 nuclee); supraîncălzire (112 grade, potrivit relatării); degradarea evidentă a performanței, resimțită de utilizator. Context: ce este Claude Code Claude Code este un agent AI de programare folosit pentru asistență la scrierea și modificarea codului; Tom’s Hardware îl menționează și într-un material separat despre utilizarea sa în optimizări software (link în articolul sursă). În cazul de față, rolul relevant nu este programarea în sine, ci faptul că agentul a identificat un proces pe care „nu l-a pus acolo”. Articolul nu oferă detalii despre cum a ajuns minerul pe sistem sau despre pașii de remediere, astfel că nu se poate stabili din informațiile disponibile vectorul de infectare ori dacă au existat și alte componente malware asociate. [...]
Un lanț de vulnerabilități din Plex permite atacatorilor să ruleze cod de la distanță și să instaleze mineri cripto , iar mii de servere rămân expuse, deși există actualizare de securitate din august, potrivit Gizmodo . Miza este operațională și financiară pentru utilizatori: resursele sistemului pot fi consumate pentru minare, iar conexiunea de internet de acasă poate fi „închiriată” fără știrea proprietarului, prin transformarea serverului într-un proxy rezidențial. Vulnerabilitățile au fost descrise într-un „lanț” de execuție de cod de la distanță fără autentificare (RCE – remote code execution), publicat de un cercetător care folosește pseudonimul ZM. În esență, un atacator care poate ajunge la un Plex Media Server expus poate obține tokenul de administrator și poate planta un fișier malițios care rulează la următoarea transcodare video. Lanțul, numit „Plex2Shell”, combină patru probleme urmărite ca CVE-2026-96652 , CVE-2026-96654, CVE-2026-96655 și CVE-2026-96656 și afectează versiunile de dinainte de 1.43.3.10861, conform descrierii tehnice publicate de ZM. Exploatare „în sălbăticie”: miner cripto și proxy rezidențial Un blogger anonim (boredhackerblog) spune că a rulat un „honeypot” (un server vulnerabil folosit ca momeală pentru a observa atacuri) pe o versiune veche de Plex și a observat exploatare activă. Conform relatării, atacatorii au livrat inițial un miner de criptomonede, iar ulterior un instrument numit „myawesomeproxy”, care ar transforma sistemul într-un proxy rezidențial – adică altcineva își poate ruta traficul prin conexiunea victimei, pentru a părea trafic „obișnuit” și pentru a-și masca adresa IP. Kraken Chief Security Officer, Nick Percoco, a avertizat într-o postare pe X că simpla oprire a minerului nu rezolvă problema, deoarece încărcătura malițioasă ar sta în folderul de codecuri al Plex și ar rula din nou la fiecare transcodare. De ce rămân multe servere neactualizate Plex a fost notificat despre problemă pe 27 iulie, a confirmat-o și a plătit un bug bounty de 500 de dolari (aprox. 2.300 lei) pe 4 august, în aceeași zi în care versiunea reparată a devenit disponibilă la descărcare. Pe 1 septembrie, compania a publicat un avertisment public și, potrivit BleepingComputer, a trimis e-mailuri utilizatorilor care erau încă pe versiuni vechi. Totuși, actualizarea nu pare să se fi propagat suficient de rapid. Datele Shadowserver citate de publicație indică aproape 49.000 de gazde încă expuse sâmbătă, inclusiv aproximativ 25.100 în America de Nord și circa 17.600 în Europa. Un motiv invocat este fragmentarea modului de actualizare: setarea de actualizare automată indicată de Plex ar fi opțională, implicit pe „Ask me” (nu instalare automată) și ar fi relevantă doar pentru Windows și macOS, în timp ce instalările pe Linux, Docker și NAS depind de manageri de pachete, reporniri de containere sau descărcări manuale. Context: Plex a mai avut incidente de securitate Gizmodo amintește că Plex a avut și alte episoade relevante, inclusiv în septembrie 2025, când compania a cerut resetarea parolelor după acces neautorizat la e-mailuri, nume de utilizator și parole „hash-uite” (stocate sub formă de amprentă criptografică). Publicația mai notează și un caz relatat anterior de Ars Technica despre incidentul LastPass din 2023, unde o aplicație media terță ar fi fost folosită ca vector pentru execuție de cod la distanță; Ars a indicat Plex pe baza unei surse „briefed”, însă LastPass și Plex nu au confirmat public legătura în același nivel de detaliu. Ce e de făcut, pe scurt Conform informațiilor din articol, riscul vizează serverele Plex expuse și neactualizate. Pragul menționat este versiunea 1.43.3.10861: sistemele rulate pe versiuni anterioare intră în categoria afectată de lanțul „Plex2Shell”. Pentru utilizatori, implicația practică este că un server lăsat în urmă cu actualizările poate deveni o sursă de cost (consum de resurse/energie) și un risc operațional (trafic rutat prin conexiunea proprie) fără semne evidente la suprafață. [...]
