Microsoft July 2026: aktywnie wykorzystywane luki w SharePoint i AD FS

Lipcowy pakiet poprawek Microsoftu wymaga czegoś więcej niż standardowego okna aktualizacyjnego. CVE-2026-56164 w SharePoint Server oraz CVE-2026-56155 w Active Directory Federation Services zostały oznaczone jako aktywnie wykorzystywane i 14 lipca trafiły do katalogu Known Exploited Vulnerabilities CISA.

Dla zespołu bezpieczeństwa najważniejsze pytanie nie brzmi „czy poprawka jest dostępna?”, lecz: czy podatny system był osiągalny w okresie ekspozycji i czy mamy dane, które pozwalają wykluczyć kompromitację? Sam zielony status z narzędzia patch management nie odpowiada na żadną z tych kwestii.

Dwie podatności, dwa różne punkty kontroli

Podatność	Warstwa	Główne ryzyko operacyjne
CVE-2026-56164	SharePoint Server	nieautoryzowany dostęp do serwera i zasobów aplikacji
CVE-2026-56155	AD FS	podniesienie uprawnień w komponencie federacji tożsamości

Oba produkty często działają blisko najcenniejszych zasobów organizacji. SharePoint przechowuje dokumenty, integracje i dane procesowe. AD FS uczestniczy w wydawaniu tokenów i egzekwowaniu zaufania między domenami. Nawet jeśli konkretny serwer nie jest wystawiony bezpośrednio do Internetu, dostęp przez VPN, reverse proxy, sieć partnerską albo przejętą stację roboczą może zmienić ocenę ekspozycji.

Najpierw ustal faktyczne środowisko

Nie zaczynaj od listy wszystkich serwerów zapisanych w CMDB. Zacznij od systemów, które naprawdę odpowiadają i obsługują ruch.

1. Znajdź wszystkie farmy SharePoint Server, w tym węzły zapasowe, środowiska testowe i serwery odzyskiwania.
2. Zidentyfikuj instancje AD FS oraz serwery Web Application Proxy.
3. Zapisz wersję produktu i poziom aktualizacji odczytany z każdego hosta.
4. Ustal ścieżki dostępu: Internet, WAF, proxy, VPN, sieci partnerów i segmenty administracyjne.
5. Wskaż właściciela biznesowego oraz osobę odpowiedzialną za logi każdego systemu.

Ta kolejność ujawnia typowy problem: system formalnie „wewnętrzny” może być dostępny przez opublikowaną aplikację, zaufaną integrację lub zbyt szeroki segment. Inwentaryzacja nazwy produktu bez mapy przepływu ruchu daje fałszywe poczucie kompletności.

Patch nie zastępuje analizy okresu ekspozycji

Aktualizację należy wdrożyć zgodnie z instrukcjami Microsoftu, ale prace powinny biec dwoma torami. Pierwszy zamyka podatność. Drugi sprawdza, czy przed zamknięciem nie doszło do nadużycia.

Dla SharePoint zabezpiecz i przeanalizuj między innymi logi IIS, ULS, zdarzenia Windows, logi WAF/reverse proxy oraz zmiany w katalogach aplikacji. Szukaj nietypowych żądań POST, nowo utworzonych lub zmodyfikowanych plików, uruchamiania procesów potomnych, nieoczekiwanych kont i zmian konfiguracji. Nie ograniczaj polowania do jednej sygnatury — publiczne IOC szybko się starzeją.

Dla AD FS przejrzyj zdarzenia administracyjne, wydawanie tokenów, zmiany konfiguracji i certyfikatów, logowania uprzywilejowane oraz aktywność serwerów proxy. Szczególnie ważne są zdarzenia poza typowym oknem administracyjnym i operacje wykonane przez konta, które normalnie nie zarządzają federacją.

Mitigacja to czas, nie zamknięcie ryzyka

Microsoft i CISA wskazują dodatkowe działania ograniczające ryzyko dla SharePoint, w tym odpowiednią konfigurację skanowania AMSI. Takie zabezpieczenie może utrudnić część ataków, lecz nie jest równoważne z instalacją poprawki. Kontrola może być wyłączona, niepełna albo ominąć wariant, którego nie rozpoznaje.

Jeżeli poprawki nie da się wdrożyć natychmiast:

• ogranicz dostęp sieciowy do zaufanych źródeł;
• wyłącz niepotrzebną publikację i stare węzły;
• zwiększ retencję oraz alertowanie dla logów aplikacyjnych i systemowych;
• monitoruj tworzenie plików oraz procesy potomne usług;
• zdefiniuj konkretny termin aktualizacji i właściciela wyjątku.

Wyjątek bez terminu i warunku zamknięcia nie jest mitigacją — jest trwałym zaakceptowaniem nieznanego ryzyka.

Jak udowodnić, że poprawka działa

Po wdrożeniu wykonaj walidację na każdym węźle, a nie tylko na głównym serwerze farmy:

1. Odczytaj rzeczywistą wersję binariów i poziom aktualizacji.
2. Sprawdź, czy węzeł wrócił do puli i obsługuje ruch.
3. Wykonaj kontrolowany test negatywny podatnej ścieżki.
4. Potwierdź działanie uwierzytelniania, wyszukiwania, integracji i procesów biznesowych.
5. Powtórz przegląd logów po aktualizacji, aby wykryć nieskuteczne próby lub regresję.
6. Sprawdź obrazy odtworzeniowe i środowisko DR — podatna kopia nie powinna wrócić przy następnym incydencie.

Pakiet dowodowy powinien zawierać host, wersję przed i po, datę, wynik testu, zakres przeanalizowanych logów, wykryte anomalie oraz zaakceptowane ryzyko resztkowe. To materiał dla właściciela ryzyka i audytu, a nie zrzut ekranu z komunikatem „completed”.

Priorytet dla zarządu i CISO

Aktywne wykorzystanie zmienia kolejność. Najpierw systemy publiczne i tożsamościowe, potem szeroko dostępne systemy wewnętrzne, a następnie izolowane środowiska. Jednocześnie nie należy utożsamiać braku alertu z brakiem incydentu. Jeżeli potrzebne zdarzenia nie były rejestrowane lub ich retencja już wygasła, poprawny wniosek brzmi „nie mamy wystarczających dowodów”.

Jeżeli SharePoint lub AD FS są częścią większego środowiska Microsoft, warto połączyć patching z audytem bezpieczeństwa IT i ręczną walidacją granic zaufania. Najpoważniejsze ścieżki ataku zwykle łączą aplikację, tożsamość, konfigurację sieci i nadmierne uprawnienia.

Źródła pierwotne i urzędowe: Microsoft Security Update Guide — July 2026, MSRC — CVE-2026-56164, MSRC — CVE-2026-56155, CISA — SharePoint hardening after new exploitations.