Atacuri în browser: de ce EDR nu vede tot și ce controlezi

Atacurile care se încheie în sesiunea de browser pot ocoli telemetria EDR, pentru că nu creează fișiere sau procese ostile pe host. NordLayer susține că în medii cu mult SaaS controalele trebuie aplicate pe trei niveluri conectate: browser, identitate și SaaS, apoi endpoint. EDR rămâne necesar pentru execuția de cod pe stație, dar nu acoperă tot ce se întâmplă în interiorul unei sesiuni autentificate.

Subiectul a fost detaliat într-un material sponsorizat publicat de BleepingComputer pe 2 octombrie 2026, semnat de Andrius Buinovskis, VP de strategie de produs la NordLayer (sursa). Textul e, în bună măsură, o prezentare de produs, deci îl tratăm ca atare: faptele tehnice descrise sunt utile, iar concluziile comerciale trebuie citite cu filtrul de rigoare.

De ce EDR nu vede atacurile care se termină în browser

EDR a fost construit pentru un model de atac cu un moment clar de execuție: un executabil pornește, un proces face ceva anormal, un fișier apare pe disc, o cheie de registru se modifică, o conexiune iese în afară în context suspect. Toate aceste semnale au un numitor comun: se întâmplă pe host, la nivel de proces.

Problema apare când acțiunea decisivă nu trece niciodată prin acel nivel. Un angajat se autentifică într-o aplicație cloud, aprobă o cerere OAuth, deschide documente sensibile sau încarcă date prin browser. Din perspectiva endpoint-ului, e o sesiune de utilizator normală. Nu s-a lansat niciun binar controlat de atacator, nu există proces pe care apărarea de endpoint să îl claseze drept malițios. Atacul s-a produs, dar urmele pe care EDR e proiectat să le analizeze lipsesc.

NordLayer citează în material incidentul Salesloft Drift din 2025, unde gruparea UNC6395 a obținut tokenuri OAuth asociate integrărilor Drift și le-a folosit pentru apeluri API masive către mediile Salesforce ale clienților. Accesul autentificat prin SaaS a permis exfiltrare de date fără un proces malware pe care EDR să îl inspecteze. E un exemplu bun pentru că nu implică nimic exotic: token valid, API legitim, volum mare.

Raportul invocat de NordLayer, Browser Security Report 2026, a analizat 504 aplicații și a constatat că accesul prin browser e prezent în tot setul, iar 79% dintre instrumente sunt disponibile doar prin browser. Cifrele sunt ale unui vendor cu interes comercial în concluzie, dar direcția e greu de contestat: browserul a devenit stratul principal de acces la aplicațiile corporate, la fluxurile de identitate, la fișiere și la consolele de administrare.

Trei mecanisme care ocolesc telemetria de endpoint

1. Phishing adversary-in-the-middle (AiTM)

Atacatorul interpune o pagină între utilizator și furnizorul real de identitate. Pagina colectează userul și parola, retransmite provocarea MFA legitimă și trimite răspunsul mai departe către serviciul real. Fluxul de autentificare reușește, iar atacatorul capturează materialul de sesiune: cookie-uri de sesiune și tokenuri OAuth emise după autentificare.

NordLayer citează un caz din 2026, urmărit de Microsoft sub numele Storm-2755, care a vizat angajați canadieni prin otrăvirea rezultatelor de căutare și reclame malițioase. Victimele care căutau termeni precum "Office 365" ajungeau pe o pagină de login Microsoft 365 controlată de atacator. Infrastructura AiTM proxya fluxul în timp real, iar atacatorii au reutilizat sesiunea furată: Microsoft a observat același ID de sesiune trecând din browserul victimei pe un user agent Axios, semnal că tokenul era refolosit din infrastructură controlată de atacator. Au urmat accesări de servicii Microsoft, căutări de informații de payroll și HR, reguli de inbox pentru a ascunde mesaje despre schimbări bancare și, în unele cazuri, acces la Workday.

Din telemetria obișnuită de proces pe endpoint, fluxul de autentificare poate părea legitim. Endpoint-ul nu dezvăluie neapărat că un proxy AiTM a interceptat sesiunea, deși alte semnale de endpoint, identitate, rețea sau XDR pot expune atacul. Aici e nuanța importantă: absența unui semnal într-un singur strat nu dovedește absența atacului. Verificarea trebuie făcută pe mai multe surse înainte de a trage concluzii.

Măsura de prevenție menționată în material este autentificarea phishing-resistant FIDO2 WebAuthn, unde răspunsul de autentificare e legat criptografic de origin-ul legitim. Peste asta, controalele de browser pot bloca destinații de phishing cunoscute, pot restricționa accesul la aplicații web neaprobate și pot opri atacul mai devreme, înainte ca tokenul să fie capturat.

2. Extensii de browser compromise

Extensiile ridică o problemă diferită de vizibilitate. Lasă fișiere în profilul de browser, iar codul lor rulează în interiorul proceselor de browser. EDR poate detecta o extensie suspectă sau trafic de rețea neobișnuit, dar comportamentul extensiei poate părea banal la nivel de host. O extensie malițioasă poate folosi API-uri standard de browser ca să citească conținut de pagină, să observe URL-uri, să interacționeze cu formulare și să trimită date prin HTTPS. Niciuna dintre aceste acțiuni nu are nevoie de un proces nou sau de un executabil suspect.

Fără context specific de browser, o echipă de securitate poate vedea traficul, dar nu știe ce extensie l-a inițiat, la ce date a avut acces sau dacă extensia era aprobată. Materialul dă un exemplu concret: în martie 2026, Microsoft a raportat extensii Chromium malițioase care se prezentau drept asistenți AI, instalate de aproximativ 900.000 de ori, cu activitate confirmată în peste 20.000 de tenanți enterprise. Extensiile colectau URL-uri vizitate și conținut din conversațiile ChatGPT și DeepSeek și trimiteau periodic datele către infrastructură controlată de atacator.

Hostul arată un proces normal de browser făcând conexiuni HTTPS. Acțiunea relevantă pentru securitate e o extensie care citește și exportă conținut de pagină. Instrumentele de endpoint pot prinde părți din activitate, dar inventarul de extensii, permisiunile și politicile oferă contextul necesar pentru a decide dacă acel comportament ar fi trebuit permis. Concluzia practică din material: echipele ar trebui să controleze direct stratul de extensii, nu să aștepte un domeniu malițios, o semnătură de malware cunoscută sau o alertă de endpoint. Adică allowlist de extensii, control de instalare și revizuire de permisiuni pentru orice extensie care poate citi sau modifica conținut web.

3. Atacuri care se încheie înainte de execuția pe host

Unele atacuri se completează integral în sesiunea web. Un site compromis, o reclamă malițioasă sau un script injectat pot modifica conținutul randat, citi date accesibile paginii, redirecționa sesiunea sau manipula clipboardul. Toate acestea se pot întâmpla în limitele permisiunilor acordate de browser, fără să scrie fișiere, fără să lanseze malware, fără să creeze un proces nou.

Un utilizator poate încărca un fișier sensibil sau lipi text confidențial într-un serviciu SaaS ori AI neautorizat, fără ca vreun malware să fie instalat. Poate fi dăunător, dar nu creează neapărat artefactele pe care EDR e construit să le găsească.

Exemplul din material e atacul ClickFix, în varianta TerminalFix observată de Microsoft în august 2026. Site-uri compromise afișau prompturi false de CAPTCHA Cloudflare. Clicking pe pasul fals de verificare copia o comandă PowerShell malițioasă în clipboard, iar pagina instruia victima să deschidă Windows Terminal sau PowerShell și să o lipească. Până în acel moment, atacatorul se bazase pe conținut de browser, manipulare de clipboard și interacțiune umană, adică exact pe zonele unde telemetria de endpoint e slabă.

Executarea comenzii schimbă însă telemetria: PowerShell rulează, se descarcă și se extrage o arhivă ZIP, urmează DLL side-loading, se creează persistență prin registru și taskuri programate, începe descoperirea în Active Directory, iar hostul compromis stabilește un tunel invers. Din acel punct, EDR are ce inspecta: execuție PowerShell, fișiere descărcate, persistență, descoperire, conexiuni de ieșire.

Diferența e crucială pentru cine proiectează controlul: controalele de browser pot opri atacul înainte de execuția pe host, blocând pagina malițioasă, restricționând accesul la clipboard sau limitând acțiuni riscante de browser. Odată ce utilizatorul rulează comanda copiată, controlul se mută în terenul endpoint-ului. Controlul trebuie să corespundă acțiunii.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un business cu echipă care lucrează zilnic în Google Ads, Meta, Shopify, un CRM și două-trei tool-uri de AI, ai deja un mediu SaaS-heavy, chiar dacă nu îl numești așa. Contul de ads, contul de analytics, adminul de magazin online, inboxul, storage-ul și asistentul AI sunt toate accesibile prin browser.

Ce se schimbă concret în prioritățile tale:

• Sesiunile sunt activul real. Un token furat prin phishing AiTM valorează mai mult decât o parolă, pentru că ocolește MFA. Dacă nu ai FIDO2 WebAuthn acolo unde se poate, măcar verifică cine are acces de admin la conturile de ads și la magazin și când s-a schimbat ultima dată parola.
• Extensiile sunt suprafață de risc. Câte extensii de Chrome are echipa instalată pe laptopuri? Câte au permisiunea de a citi și modifica date pe toate site-urile? O extensie care se dă drept asistent AI și are acces la tot ce tastezi în browser e un canal de scurgere pe care multe firme mici nu îl verifică niciodată.
• OAuth și integrările sunt ușa din spate. Orice aplicație conectată la magazinul tău, la CRM sau la contul de ads prin OAuth are acces programatic. Fă inventarul integrărilor active și revizuiește-l periodic. Nu e o verificare completă dacă te uiți doar la cine are parola.
• Upload-urile și clipboardul sunt scurgeri legitime. Un export de clienți lipit într-un tool AI necunoscut nu declanșează nimic. Dacă lucrezi cu date de clienți, stabilește clar unde e permis să lipești și unde nu.

Ce nu poți scoate din materialul NordLayer: nu îți poate spune cât te costă un incident, cât scade CPA-ul după ce aplici politici de extensii sau dacă ești în regulă legal. Sunt alte discuții, care se rezolvă cu propriile date, nu cu un articol de vendor.

O abordare pe trei straturi, propusă, nu dovedită

Materialul propune trei niveluri conectate de control: browser, identitate și SaaS, apoi endpoint. Logica are sens. Controalele de browser sunt necesare înainte ca datele să ajungă într-un serviciu SaaS sau AI neautorizat. Web threat protection poate bloca phishing și site-uri malițioase. Politicile de extensii pot împiedica cod neaprobat să citească conținut web. Browser DLP poate restricționa încărcări, descărcări și copiere-lipire în funcție de destinație.

Tratează însă propunerea ca pe o ipoteză de implementare, nu ca pe un rezultat demonstrat. Pași de verificat înainte de a investi:

1. Inventariază aplicațiile accesibile prin browser, cu cine le folosește și ce date ating. Fără inventar, orice politică e ghicit.
2. Verifică metodele de autentificare. Unde se poate FIDO2 WebAuthn, activează. Unde nu, documentează de ce și pune măsuri compensatorii.
3. Fă lista extensiilor instalate, cu permisiuni și număr de utilizatori. Decizia de a bloca sau permite e a ta, nu a unui furnizor.
4. Testează o politică pe un grup mic înainte de rollout general. Măsoară câte blocări legitime apar și cât timp pierde echipa.
5. Definește cine răspunde când un control blochează o acțiune legitimă. Fără un proces de excepții, oamenii ocolesc controlul.

Un audit automat incomplet nu dovedește că o funcție lipsește sau că un atac a trecut. Înseamnă doar că nu ai încă proba. Verifică la nivel de identitate, browser și endpoint înainte să declari ceva închis.

FAQ

Atacurile din browser pot fura date fără ca EDR să alerteze? Da, în anumite condiții. Când acțiunea decisivă se întâmplă în sesiunea web sau în fluxul de identitate, fără să creeze un proces nou sau un executabil suspect, artefactele pe care EDR le analizează pot să nu existe. Alte semnale, de identitate, rețea sau XDR, pot expune totuși atacul. Nu poți concluziona că totul e în ordine doar pentru că un singur strat nu a semnalat nimic.

FIDO2 WebAuthn rezolvă complet problema phishingului? În material, FIDO2 WebAuthn e prezentat drept cea mai bună metodă de prevenție pentru multe atacuri AiTM, pentru că răspunsul de autentificare e legat criptografic de origin-ul legitim. Nu acoperă însă extensiile compromise sau scurgerile prin upload și clipboard. Sunt straturi diferite de risc și au nevoie de controale diferite.

Trebuie să renunț la EDR dacă îmi mut atenția pe browser? Nu. Materialul e explicit: EDR rămâne necesar pentru execuția de cod pe stație, malware, persistență și comportament la nivel de proces. În cazul TerminalFix, odată ce comanda copiată a fost executată, activitatea a intrat în terenul EDR. Problema nu e EDR, ci așteptarea ca EDR să acopere acțiuni care nu ajung niciodată pe host.

Arc final: AI-ul ajută, decizia rămâne la om

Un asistent AI poate accelera partea bună: să structureze inventarul de aplicații și integrări OAuth, să grupeze lista de extensii după permisiuni, să redacteze politici interne pe bază de șabloane, să genereze checklist-uri de verificare pe cele trei straturi. Te scutește de muncă repetitivă.

Ce nu face AI-ul: nu decide ce extensie blochezi și ce riști să strici, nu își asumă că o politică de browser va bloca un flux legitim de lucru, nu răspunde când un cont de ads e compromis la 2 noaptea. Decizia și execuția rămân umane. Media buyer-ul sau omul de operațiuni știe ce unelte sunt critice pentru campanii și ce se poate restricționa fără să oprească business-ul.

Pasul concret îl face ALLSoft Agency: punem la punct inventarul de acces, prioritizăm ce se blochează și ce se documentează, apoi executăm pe rând, cu verificare la fiecare etapă. Fără hype, fără promisiuni de zero incident. Doar ordine în ce controlezi și transparență în ce nu știi încă.