W raporcie opublikowanym 30 października 2026 r. Microsoft opisał dwa włamania, w których napastnicy podszywali się pod pracowników pomocy IT w Microsoft Teams, uzyskiwali zdalny dostęp do komputerów, a następnie nadużywali usług certyfikatów Active Directory (AD CS). Teams był kanałem socjotechniki; Microsoft przypisał eskalację błędnej konfiguracji AD CS, a nie podatności samej aplikacji. W obu przypadkach użyto innej ścieżki do zdobycia certyfikatów uprzywilejowanych kont. Microsoft opisał przebieg incydentów i działania obronne.
Od wiadomości w Teams do zdalnego dostępu
Napastnicy kontaktowali się z pracownikami przez zewnętrzne wiadomości i połączenia w Teams, podszywając się pod dział IT lub pomoc techniczną. Przekonywali użytkowników, by uruchomili narzędzie Quick Assist i udostępnili zdalny dostęp. Po uzyskaniu kontroli umieszczali archiwum na komputerze, rozpakowywali je do nowego folderu zapisywalnego przez użytkownika i uruchamiali skrypty przy użyciu przenośnych środowisk Python, Bun lub Java.
Sam plik o nazwie Bun, Java czy Python nie przesądza o incydencie. Wzorzec wart zbadania łączy kontekst nieoczekiwanej sesji zdalnej z pochodzeniem procesu, ścieżką uruchomionego pliku, skryptem i późniejszą aktywnością w sieci lub usługach katalogowych.
Dwie drogi od zdalnego dostępu do AD CS
W pierwszym przypadku napastnicy wykorzystali podatny szablon certyfikatu ESC1. Błędna konfiguracja pozwalała wnioskującemu podać informacje o tożsamości i uzyskać certyfikat uwierzytelniający reprezentujący uprzywilejowane konto. Pierwsza fala objęła trzy konta użytkowników i jedną stację roboczą; napastnicy zdobyli certyfikaty dla trzech uprzywilejowanych kont. Około 90 minut później zaatakowali 16 kolejnych użytkowników i drugą stację, a następnie uzyskali certyfikaty dla ośmiu kolejnych uprzywilejowanych kont.
Microsoft Defender ograniczył działania wobec objętych reakcją tożsamości i zablokował ponad 1 000 późniejszych prób dostępu do plików przez SMB oraz logowań. Jedno uprzywilejowane konto wyłączono z automatycznego ograniczania, więc pozostało dostępne dla napastnika. W ciągu kilku sekund od uzyskania jednego z certyfikatów rozpoczęła się operacja DCSync, czyli próba replikacji danych katalogowych. Napastnik użył też wyłączonego konta, by dostać się do serwera plików i przesłać dane na zewnętrzny serwer SFTP.
Drugi przypadek wykorzystywał PetitPotam i ESC8. PetitPotam wymusił uwierzytelnienie kontrolera domeny przez NTLM, a napastnik przekazał to uwierzytelnienie do usługi AD CS Web Enrollment i uzyskał certyfikat dla konta kontrolera. Potem użył certyfikatu do uwierzytelnienia Kerberos przez PKINIT i uzyskania biletu TGT. Po alertach Microsoft Defender klient odizolował powiązaną stację roboczą; Microsoft nie zaobserwował dalszego postępu ataku.
Jakie sygnały mogą połączyć zespoły bezpieczeństwa?
Microsoft wskazał cztery obszary do sprawdzenia: nietypowe zewnętrzne kontakty w Teams i sygnały podszywania się; uruchamianie Bun lub Java ze ścieżek przygotowawczych z prefiksem KB; aktywność sieciową tych środowisk; oraz alerty dotyczące przekaźnika NTLM, Certificate Services, PKINIT i żądań biletów Kerberos.
Praktyczna analiza powinna połączyć zapis rozmowy lub połączenia i sesji zdalnej z procesami uruchomionymi na komputerze, wnioskami i wydaniem certyfikatów oraz aktywnością kont i Kerberos. Pojedynczy alert albo obecność środowiska Bun czy Java to punkt wyjścia do sprawdzenia kontekstu, nie samodzielny dowód włamania. Microsoft udostępnił też przykładowe zapytania do zaawansowanego wyszukiwania; należy je dostosować do środowiska i zestawiać wyniki z innymi zdarzeniami.
Reakcja musi objąć certyfikaty i bilety Kerberos
Zmiana hasła ani ponowne przygotowanie zainfekowanej stacji nie unieważniają wydanego certyfikatu. Microsoft zaleca osobno zidentyfikować i unieważnić nieautoryzowany certyfikat oraz sprawdzić aktywne bilety Kerberos, ponieważ wcześniej wydane bilety nie tracą ważności automatycznie po unieważnieniu certyfikatu.
W zabezpieczeniach AD CS zespoły powinny sprawdzić szablony certyfikatów uwierzytelniających pod kątem uprawnień do rejestracji, możliwości podawania tożsamości i zasad zatwierdzania. Microsoft zaleca także usunięcie zbędnych punktów Web Enrollment, wymuszenie HTTPS i Extended Protection for Authentication (EPA) oraz wyłączenie NTLM w usługach rejestracji, jeśli pozwala na to środowisko operacyjne. Szczegóły ochrony przed przekaźnikiem NTLM w AD CS opisuje oficjalna dokumentacja Microsoftu. Każde konto lub urządzenie wyłączone z automatycznej reakcji wymaga przypisanego działania ręcznego.
