Securizarea unui depozit Server SharePoint Server necesită aplicarea unor controale suplimentare pe lângă antivirusul integrat, care scanează fiecare fișier o singură dată, la încărcare sau descărcare, folosind un singur motor de scanare. Multiscanning, CDR (Content Disarm and Reconstruction), DLP (Data Loss Prevention) și rescanarea continuă elimină vulnerabilitățile care permit malware-ului și ransomware-ului să rămână inactive.
Principalele concluzii
- Antivirusul integrat Server SharePoint Server(VSAPI sau AMSI) scanează fiecare fișier cu un singur motor, doar în momentul încărcării sau descărcării. Nu rescanează niciodată fișierele deja stocate.
- Un fișier considerat „curat” încă din prima zi își păstrează această calificare pe termen nelimitat, astfel încât programele malware și ransomware pot rămâne ascunse, nedetectate, pe măsură ce semnăturile și modelele de detectare evoluează în jurul lor.
- Istoricul versiunilor agravează expunerea: fiecare copie păstrată prezintă același risc legat de datele nescanate și stocate în repaus ca și fișierul actual.
- Atacurile ToolShell/Warlock din iulie 2025 au arătat că atacatorii au plasat fișiere web-shell pe care o scanare bazată pe un singur motor și realizată la un moment dat nu a fost concepută să le detecteze.
- Pentru a elimina această vulnerabilitate este necesar un set de măsuri de control pe mai multe niveluri. Acest set include scanarea multiplă, CDR (Content Disarm and Reconstruction), DLP (Data Loss Prevention) și rescanarea continuă, pe lângă scanarea nativă.
- MetaDefender Security™ este platforma OPSWAT destinată protecției datelor la nivel de întreprindere, care utilizează tehnologiile Metascan™ Multiscanning™, Deep CDR™ și Proactive DLP™ pentru a inspecta atât fișierele nou încărcate, cât și cele deja stocate.
Atunci când utilizatorii și administratorii SharePoint din mediul local încarcă un fișier, acesta este scanat fie cu un antivirus de la terți, fie cu motoare compatibile cu AMSI (cum ar fi Microsoft Defender). Dacă fișierul trece de această scanare inițială, este considerat procesat. Odată curățat, rămâne curat pentru totdeauna. Tocmai această presupunere permite ca încărcăturile de malware și ransomware să rămână nedetectate în depozit, uneori chiar ani de zile.
Microsoft afirmă acest lucru în mod direct: protecția împotriva programelor malware oferită de SharePoint poate limita pagubele, dar nu constituie un singur punct de apărare.
În cazul sectoarelor BFSI (bănci, servicii financiare și asigurări), al sănătății, al administrației publice, precum și al mediilor OT (tehnologie operațională) sau al infrastructurilor critice, datele expuse riscului includ documentele de conformitate, dosarele pacienților, dosarele de caz și documentația tehnică. Toate acestea se află într-o arhivă care crește de la an la an, fără ca nimeni să revină asupra conținutului existent pentru a-l reexamina.
Ceea ce urmează se rezumă la trei aspecte: modul în care funcționează de fapt scanarea antivirus în SharePoint, ce nu acoperă aceasta și cum ar trebui să arate un sistem de securitate eficient și pe mai multe niveluri pentru depozitul de fișiere din SharePoint.
Ce nu acoperă funcția nativă de scanare a SharePoint
Microsoft este foarte clar, avertizând utilizatorii că funcțiile antivirus integrate în SharePoint pot conține viruși, dar nu sunt concepute ca un singur punct de apărare împotriva programelor malware. Merită menționate trei puncte vulnerabile specifice.
Date deja stocate
Detectarea devine rapid depășită. Deoarece motorul de detectare nu este activat în mod periodic, verdictul unui fișier reflectă doar ceea ce un singur motor a putut identifica în momentul scanării fișierului.
Istoric versiuni
Bibliotecile SharePoint, în cazul în care istoricele versiunilor sunt activate, păstrează fiecare versiune salvată ca o copie separată a fișierului. În funcție de politicile de gestionare a versiunilor ale unei organizații, un singur fișier poate acumula, în timp, sute de versiuni anterioare.
Documentația Microsoft privind istoricul versiunilor nu menționează efectuarea de scanări împotriva programelor malware asupra versiunilor stocate.
Prin urmare, fiecare versiune istorică stocată într-o bibliotecă prezintă același nivel de expunere în stare de repaus ca și versiunea actuală. În bibliotecile cu actualizări frecvente, expunerea se acumulează în timp. Se pot acumula sute de versiuni nescanate ale aceluiași fișier (infectat). Riscurile cresc exponențial odată cu adâncimea istoricului versiunilor.
Amenințări necunoscute sau de tip „zero-day”
O vulnerabilitate de tip „zero-day” va trece de scanare la fel ca un fișier curat, pur și simplu pentru că nu există încă un motor care să o semnaleze. Și deoarece SharePoint nu rescanează conținutul existent ulterior, un fișier cu vulnerabilitate de tip „zero-day” care trece de scanare în prima zi nu va fi verificat din nou în a două sutea zi, chiar și după ce furnizorul lansează o actualizare a semnăturilor care l-ar detecta.
Amenințările necunoscute urmează aceeași logică. În lipsa unei semnături asociate, analiza statică (ceea ce fac motoarele antivirus) nu poate detecta amenințarea.
Notă: acestea reprezintă mai degrabă lacune în domeniul de aplicare decât defecte. Antivirusul nativ Server SharePoint Server a fost conceput pentru verificări punctuale la anumite puncte de interacțiune, nu pentru revalidarea continuă a unui depozit de date în continuă creștere și cu versiuni diferite, în contextul unui peisaj al amenințărilor în continuă evoluție.
În iulie 2025, Microsoft a dezvăluit existența unei exploatări active a unui lanț de vulnerabilități care permitea executarea de cod la distanță fără autentificare, afectând Server SharePoint instalate local: CVE-2025-49706, CVE-2025-49704, la care s-au adăugat ulterior CVE-2025-53770 și CVE-2025-53771. Exploit-ul nu necesita credențiale sau autentificare pentru a funcționa.
Microsoft a remediat apoi problema, iar lanțul de exploatare a primit un nume: ToolShell.
Conform analizei realizate de Eye Security, citată de revista Infosecurity Magazine, au fost identificate 396 de sisteme compromise în cadrul a 145 de organizații din 41 de țări. Sectorul guvernamental a fost cel mai grav afectat, reprezentând 30% din infecțiile confirmate, iar numai Statele Unite au reprezentat 31% din total. În altă ordine de idei, Fundația Shadowserver a raportat că peste 10.700 de instanțe SharePoint au rămas expuse, accesibile oricui folosea același lanț de exploatare, chiar și după ce vulnerabilitatea, care a compromis sute de organizații, a fost făcută publică. Storm-2603, unul dintre grupurile din spatele exploatării, a transformat această expunere într-o încărcătură de tip ransomware Warlock.
Odată ce au pătruns în sistem, Storm-2603 a folosit datele de autentificare furate și instrumente administrative legitime pentru a se deplasa lateral între sisteme. Această mișcare nu a declanșat nicio alarmă, deoarece s-a bazat pe instrumente care ar fi trebuit să se afle deja acolo. Storm-2603 a instalat web shell-uri și a sustras date importante. Atacatorii și-au menținut accesul chiar și după ce vulnerabilitatea a fost remediată, deoarece furaseră deja cheile necesare pentru a falsifica token-uri de autentificare valide.
ToolShell a fost construit pe baza a patru vulnerabilități CVE, combinate între ele, cu mecanisme de ocolire a patch-urilor integrate încă de la început. Vulnerabilitățile CVE-2025-53770 și -53771 există tocmai pentru că remediile inițiale pentru CVE-2025-49704 și -49706 puteau fi ocolite.
Ceea ce contează cu adevărat este faptul că un atacator s-a adaptat mai repede decât ciclul de lansare a patch-urilor, de două ori, asupra aceleiași ținte, în decurs de câteva săptămâni.
Măsurile de control statice, cum ar fi programele antivirus individuale care verifică un fișier o singură dată, comparându-l cu semnăturile unui singur furnizor, nu au fost concepute, de la bun început, pentru a detecta un lanț de exploatări la nivel de server. În plus, acestea nu pot oferi protecție împotriva unui atacator care revine după aplicarea patch-ului cu o metodă de ocolire a acestuia.
ToolShell demonstrează nivelul de sofisticare la care se ajunge în prezent, vizând în mod specific serverele SharePoint. Nu există niciun motiv să presupunem că aceasta a fost ultima dată când s-a produs un astfel de atac. Datele stocate pe aceste servere sunt protejate de un sistem conceput să țină pasul cu evoluția amenințărilor sau de o scanare care verifică o singură dată și consideră că treaba este rezolvată?
Ca să fim corecți, ToolShell nu a fost un document rău intenționat care a reușit să treacă neobservat de scanarea la încărcare. Dar web shell-ul (spinstall0.aspx și variantele sale redenumite) pe care l-au plasat atacatorii? Acela este un fișier. A rămas pe server, iar faptul că a fost sau nu semnalat a depins de aceleași limite descrise anterior: un singur motor de scanare, o singură verificare, la un singur moment dat.
Acesta este mecanismul care leagă acest incident de argumentul mai general. Aplicarea patch-ului blochează în mod specific lanțul de exploatare ToolShell. Nu are niciun efect asupra următorului fișier nescanat care se află deja într-un depozit.
Modul în care soluția MetaDefender™ Storage Security aceste cerințe
Storage Security MetaDefender™ Storage Security este platforma OPSWAT protecției datelor la nivel de întreprindere, concepută pentru a asigura securitatea fișierelor stocate în medii locale, hibride și native în cloud, folosind tehnologiile Metascan™ Multiscanning, Deep CDR™ și Proactive DLP™, scanând atât fișierele nou încărcate, cât și conținutul deja stocat.
Pentru utilizatorii SharePoint, platforma poate rezolva atât problema conținutului inactiv, cât și limitările generate de detectarea limitată la un singur motor. Iată cum se întâmplă acest lucru:
- Scanare cu peste 30 de motoare antimalware prin intermediul tehnologiei Metascan™ Multiscanning; o amenințare omisă de un furnizor are alte 29 de șanse de a fi detectată.
- Tehnologia Deep CDR™ elimină punctele oarbe din procesul de detectare; tehnologia Deep CDR™ descompune și reconstruiește fișierele într-o structură sigură, utilă pentru amenințările de tip „zero-day” și cele necunoscute ascunse în fișierele de productivitate. Fișierul este descompus indiferent dacă a fost sau nu recunoscută o amenințare.
- Tehnologia Proactive DLP™ reduce riscurile de scurgere a datelor prin identificarea, blocarea și cenzurarea datelor sensibile sau confidențiale din fișiere. Pentru mediile din sectoarele BFSI, sănătate și administrație publică, reglementate de cerințele PCI DSS, PHI sau CUI, aceasta reprezintă o măsură de control a conformității care se adaugă protecției împotriva programelor malware și înregistrărilor de audit.
Opțiuni multiple de scanare în MetaDefender pentruStorage Security
Reprezentând o diferență esențială față de modelul nativ al SharePoint, MetaDefender Storage Security scanarea în timp real, programată și la cerere a conținutului stocat deja în depozit. Protecția în timp real asigură securitatea fișierelor nou încărcate în câteva secunde, în timp ce scanările programate și la cerere garantează că fișierele existente și versiunile anterioare rămân protejate.
Implementarea rămâne acolo unde ai nevoie de ea
Storage Security MetaDefender Storage Security poate fi implementată prin diverse modele: servere fizice pentru instalări directe pe hardware, platforme de virtualizare (compatibile cu VMware, Hyper-V și XenServer), IaaS (Infrastructură ca serviciu) de la principalii furnizori de servicii cloud sau prin implementări containerizate în clustere Kubernetes.
Întrebări frecvente
1. SharePoint Server automat fișierele în căutarea de programe malware?
Da, dar numai în anumite momente. SharePoint Server scana documentele la încărcare, descărcare și editare online, folosind un singur motor prin intermediul VSAPI sau al funcției de antivirus pentru documente bazată pe AMSI. Nu rescanează automat fișierele deja stocate în biblioteci.
2. Poate un program malware să rămână nedetectat într-o bibliotecă Server SharePoint?
Da. Integrările antivirus native ServerSharePoint Server(VSAPI sau AMSI) scanează un fișier în momentul încărcării sau descărcării, utilizând semnăturile disponibile la acel moment ale unui singur motor de scanare. Fișierele nu sunt scanate din nou ulterior, astfel încât un fișier care era curat sau pur și simplu nerecunoscut atunci când semnăturile motorului de scanare erau mai puțin actualizate poate rămâne în bibliotecă pe termen nelimitat.
3. SharePoint Server fișierele care sunt deja stocate?
Nu. Scanarea nativă se bazează pe evenimente și este declanșată de activitatea de încărcare sau descărcare. Aceasta nu se execută periodic asupra conținutului existent, inclusiv asupra versiunilor mai vechi ale fișierelor păstrate în istoricul versiunilor.
4. Cum pot atacatorii să folosească SharePoint pentru a distribui programe malware, nu doar pentru a le stoca?
Atacatorii pot folosi funcțiile de partajare și sincronizare ale SharePoint — linkuri externe sau pentru invitați, biblioteci sincronizate sau site-uri compromise care găzduiesc documente de phishing și linkuri dăunătoare — pentru a transmite un fișier deja pregătit într-un depozit către alți utilizatori și dispozitive finale.
5. SharePoint Online (Microsoft 365) este afectat de aceleași vulnerabilități și de ToolShell?
Nu. Lanțul de exploatare ToolShell a afectat Server SharePoint local; SharePoint Online nu a fost afectat. Limitările privind scanarea datelor stocate și a sistemelor cu un singur motor, discutate aici, se aplică, de asemenea, Server locale Server .
6. Ce este ToolShell și aplicarea patch-urilor rezolvă complet problema?
ToolShell este un exploit în lanț (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, CVE-2025-53771) care permite executarea de cod la distanță fără autentificare pe Server SharePoint local. Aplicarea patch-urilor remediază vulnerabilitățile, dar, deoarece atacatorii au furat cheile sistemului, organizațiile trebuie, de asemenea, să rotească cheile și să identifice shell-urile web deja plasate.
7. De ce trebuie să schimb cheile de sistem ASP.NET după aplicarea patch-urilor?
Atacatorii care v-au furat cheile sistemului pot genera tokenuri de autentificare valide chiar și după aplicarea patch-ului. Recomandarea CISA este să schimbați cheile, să aplicați actualizarea, să schimbați din nou cheile și să reporniți IIS cu comanda iisreset.exe, astfel încât aplicarea patch-ului să elimine efectiv atacatorul.
8. Activarea AMSI protejează SharePoint împotriva ToolShell?
Funcția de filtrare a cererilor AMSI (activată implicit începând cu actualizările din septembrie 2023, de preferință în modul complet) verifică cererile primite și poate bloca exploatările neautentificate ale ToolShell. Această funcție este distinctă de funcția antivirus pentru documente bazată pe AMSI, care scanează conținutul fișierelor la încărcare și descărcare.
