ToolShell: masowy atak 0-day na SharePoint (2025)

W lipcu 2025 roku administratorzy lokalnych serwerów Microsoft SharePoint przeżyli jeden z gorszych tygodni dekady. Podatność oznaczona jako CVE-2025-53770 — szybko ochrzczona „ToolShell” — pozwalała przejąć serwer SharePoint bez żadnego logowania, zdalnie, przez pojedyncze żądanie HTTP. Zanim Microsoft zdążył wydać pełną łatkę, atakujący masowo skanowali internet i zakładali webshelle. To modelowy przykład podatności typu „załatana, ale nie do końca” i tego, jak szybko exploit potrafi wyprzedzić obronę.

Co to jest ToolShell i skąd się wziął

Łańcuch ToolShell zadebiutował na zawodach Pwn2Own Berlin wiosną 2025, gdzie badacze pokazali połączenie dwóch błędów SharePointa (CVE-2025-49704 i CVE-2025-49706) dających zdalne wykonanie kodu. Microsoft wydał łatki w lipcowym „wtorku poprawek” — ale okazało się, że da się je obejść. Warianty obejścia dostały nowe numery: CVE-2025-53770 (RCE, CVSS 9.8) i CVE-2025-53771 (spoofing). I to właśnie te obejścia trafiły do masowej eksploatacji, zanim powstała skuteczna poprawka.

Mechanika jest podręcznikowa: atak wykorzystywał deserializację i podrobiony nagłówek Referer prowadzący do endpointu ToolPane.aspx, by wgrać na serwer plik ASPX (webshell). Kluczowy detal, który uczynił atak tak groźnym: napastnicy wykradali z serwera klucze kryptograficzne ASP.NET (MachineKey). Mając te klucze, mogli generować ważne tokeny __VIEWSTATE i wracać na serwer nawet po jego załataniu — dopóki klucze nie zostały wymienione.

Skala: kto oberwał

Firmy monitorujące zagrożenia liczyły dziesiątki, a potem setki skompromitowanych organizacji na całym świecie — od administracji publicznej i uczelni, przez firmy energetyczne, po sektor finansowy. Amerykańska CISA błyskawicznie dopisała CVE-2025-53770 do katalogu KEV (Known Exploited Vulnerabilities). W eksploatację zaangażowały się zarówno grupy powiązane z państwami, jak i operatorzy ransomware — schemat znany: krytyczny 0-day najpierw służy szpiegostwu, potem trafia do przestępczości nastawionej na okup.

Ważne zastrzeżenie: dotyczyło to wyłącznie SharePoint Server on-premises. SharePoint Online w Microsoft 365 nie był podatny — to kolejny argument w odwiecznej dyskusji o tym, kto łata: Ty czy dostawca chmury.

Wnioski dla obrońców

ToolShell to skarbnica lekcji, które wykraczają daleko poza jeden produkt:

Łatka to nie zawsze koniec. Obejście oryginalnej poprawki pokazuje, że po krytycznym CVE trzeba śledzić nie tylko sam biuletyn, ale i doniesienia o bypassach. Sama instalacja lipcowej łatki nie wystarczała — konieczne było wgranie kolejnej i, co kluczowe, rotacja MachineKey oraz restart IIS. Firmy, które tylko „załatały”, zostawały z aktywnym dostępem napastnika.

Zakładaj kompromitację, nie tylko podatność. Przy 0-dayu w masowej eksploatacji pytanie nie brzmi „czy jesteśmy podatni”, tylko „czy już nas nie przejęto”. To wymaga reagowania na incydent: przegląd logów IIS pod kątem żądań do ToolPane.aspx, poszukiwanie nietypowych plików .aspx w katalogach LAYOUTS, analiza pod kątem wykradzionych kluczy.

Kradzież sekretów uodparnia na łatanie. To najważniejsza lekcja techniczna: gdy atakujący wyniesie klucze, hasła czy tokeny, załatanie luki go nie usuwa. Dlatego po każdym poważnym włamaniu rotacja sekretów jest równie ważna jak łatka — pisaliśmy o tym przy wyciekach tokenów OAuth.

Systemy wystawione do internetu to priorytet. SharePoint, VPN, serwery pocztowe — wszystko, co osiągalne z sieci, wymaga najkrótszych okien łatania i najściślejszego monitoringu. To ten sam wzorzec, co przy CitrixBleed 2 czy SAP NetWeaver w tym samym roku.

Co zrobić, jeśli masz SharePoint on-prem

Nawet dziś, jeśli utrzymujesz lokalny SharePoint: potwierdź, że zainstalowano wszystkie poprawki z lipca 2025 i późniejsze, zrotuj MachineKey i zrestartuj IIS, włącz integrację z AMSI, a następnie przejrzyj logi wstecz pod kątem śladów z okresu ekspozycji. Jeśli serwer był wystawiony do internetu w krytycznym oknie — potraktuj to jako incydent do wyjaśnienia, nie jako zamknięty temat.

Najczęstsze pytania (FAQ)

Czy moja firma była zagrożona, skoro używamy SharePoint w Microsoft 365? Nie w zakresie ToolShell — podatny był wyłącznie SharePoint Server instalowany lokalnie. To dobra ilustracja modelu współdzielonej odpowiedzialności: w chmurze łatanie tej warstwy leży po stronie Microsoftu.

Załataliśmy w lipcu 2025. Czy jesteśmy bezpieczni? Tylko jeśli łatka objęła obejścia (CVE-2025-53770/53771), a Wy dodatkowo zrotowaliście klucze MachineKey. Sama pierwotna poprawka była obchodzona, a bez rotacji kluczy napastnik z wcześniejszego dostępu mógł wracać mimo łatki.

Jak sprawdzić, czy ktoś już nas nie przejął? Przejrzyj logi IIS pod kątem POST-ów do ToolPane.aspx z podejrzanym Referer, poszukaj nowych plików .aspx w katalogach warstwy prezentacji i sprawdź nietypowe procesy potomne w3wp.exe. W razie wątpliwości — zleć analizę powłamaniową.

Czego ToolShell uczy o łataniu w ogóle? Że proces nie kończy się na „zainstalowano poprawkę”. Po krytycznych CVE w systemach wystawionych do internetu trzeba śledzić bypassy, rotować sekrety i weryfikować, czy nie doszło już do kompromitacji. To element dojrzałego zarządzania podatnościami.

Czy pentest wykryłby taką ekspozycję? Regularny test penetracyjny infrastruktury zewnętrznej znajduje wystawione, przestarzałe usługi i ocenia okna łatania — czyli dokładnie te warunki, które czynią z 0-dayów katastrofę. Nie przewidzi konkretnego 0-daya, ale pokaże, jak duża jest Twoja powierzchnia ataku, gdy taki się pojawi.

Podsumowanie

ToolShell (CVE-2025-53770) to podręcznikowy przykład, że w bezpieczeństwie liczy się nie tylko „czy załatane”, ale „jak szybko i jak kompletnie”. Masowa eksploatacja ruszyła w dni, obejście łatki uczyniło pierwszą poprawkę niewystarczającą, a kradzież kluczy uodporniła atak na samo łatanie. Jeśli utrzymujesz systemy wystawione do internetu i chcesz wiedzieć, jak szybko jesteś w stanie zareagować na kolejny taki scenariusz — porozmawiajmy o testach i monitoringu.

Źródła i dalsza lektura: Microsoft MSRC, CISA KEV, Sekurak, Niebezpiecznik.