TeamFiltration: 5714 kont Microsoft 365 na celowniku

Najważniejsza informacja nie dotyczy jednak samej skali. Wszystkie siedem przejętych kont było niezarządzanymi kontami funkcjonalnymi lub usługowymi. Nie miały MFA ani wcześniejszej legalnej aktywności widocznej w telemetrii Proofpoint. W tej samej kampanii badacze nie potwierdzili przejęcia żadnego osobistego konta pracownika.

To przypadek, w którym ochrona użytkowników nie zamknęła całej powierzchni tożsamości. Aktywne konto pozostawione bez właściciela, przeglądu i właściwego modelu uwierzytelniania może nadal otwierać dostęp do usług chmurowych.

Co Proofpoint zobaczył w kampanii TeamFiltration

Kampania, śledzona przez Proofpoint jako UNK_CondorFiltration, trwała w trzech falach od 21 lipca do 16 sierpnia 2026. Koncentrowała się przede wszystkim na organizacjach w Chile, szczególnie w handlu detalicznym i sektorze finansowym.

TeamFiltration jest publicznym frameworkiem ofensywnym do środowisk Microsoft 365. Umożliwia między innymi enumerację kont, password spraying oraz działania po uzyskaniu dostępu. Proofpoint powiązał kampanię z tym narzędziem na podstawie charakterystycznego, domyślnie używanego user-agenta.

Badacze odnotowali 5714 unikalnych kont będących celem i 1487 źródłowych adresów IP w AWS EC2. Jeden duży sprzedawca detaliczny odpowiadał za 78,3% obserwowanych zdarzeń uwierzytelnienia. To właśnie w jego środowisku wystąpiło siedem potwierdzonych przejęć.

Siedem przejęć i jeden wspólny wzorzec

Proofpoint przeanalizował telemetrię siedmiu przejętych kont. Wszystkie były kontami funkcjonalnymi lub usługowymi, a w badanym okresie nie miały wcześniejszych legalnych sesji użytkownika. Sześć z nich zostało przejętych w ciągu siedmiu minut.

Badacze oceniają, że taki wzorzec silnie wskazuje na domyślne albo przewidywalne hasła pozostawione po utworzeniu kont. To wniosek z telemetrii, nie obserwacja samego procesu nadawania haseł. Warto zachować to rozróżnienie: źródło opisuje prawdopodobną przyczynę, a nie bezpośredni zapis konfiguracji każdego konta.

Każde z siedmiu kont nie miało wymuszonego MFA. Jednocześnie osobiste konta pracowników nie zostały w tej kampanii potwierdzone jako przejęte.

Dlaczego zapomniane konto usługowe jest innym problemem niż pracownik

Konto pracownika zwykle ma właściciela, widoczną historię logowań i naturalny moment zakończenia cyklu życia, gdy osoba zmienia rolę albo odchodzi. Konto utworzone do obsługi procesu biznesowego może działać latami, mimo że pierwotny projekt, integracja lub właściciel już się zmienili.

Microsoft w dokumentacji dotyczącej kont usługowych zaleca przypisanie właściciela, udokumentowanie celu, zakresu uprawnień, oczekiwanego czasu życia i cyklu przeglądów. Dla automatyzacji firma rekomenduje managed identities, a gdy nie można ich użyć — service principals. Zwykłe konta użytkowników używane jako konta usługowe są rozwiązaniem niezalecanym.

To ważne także przy interpretacji hasła „włącz MFA”. To dobra kontrola dla kont użytkowników, ale automatyczne workload identities mają inny model uwierzytelniania. Problem trzeba więc zacząć od ustalenia, czym dana tożsamość jest i czy w ogóle powinna pozostać kontem użytkownika.

Co działo się po uzyskaniu dostępu

W większości przejętych kont Proofpoint widział dostęp do Microsoft Office, OneDrive i Teams z tej samej infrastruktury AWS. Badacze zaznaczają, że same logi logowania nie potwierdzają eksfiltracji danych, nawet jeśli wzorzec odpowiada możliwościom automatycznego trybu TeamFiltration.

W jednym przypadku około 90 sekund po przejęciu napastnik przeszedł na niemiecki węzeł VPN. Następnie próbował dostać się do firmowego VPN, otworzył Azure Portal, Microsoft 365 Portal i SharePoint oraz wywołał żądanie tokenu Microsoft Graph.

Próba wejścia do firmowego VPN została zablokowana przez MFA lub Conditional Access. W Azure Portal pojawił się natomiast monit o rejestrację MFA, co według Proofpoint wskazywało, że przejęte konto nie miało wcześniej skonfigurowanego MFA.

Co sprawdzić w Microsoft 365 i Entra

Pierwszym zadaniem jest znalezienie kont, które nie mają jasnego właściciela i celu. Szczególnie istotne są konta utworzone jak zwykli użytkownicy, lecz faktycznie używane przez aplikacje, skrypty, urządzenia lub procesy. Warto porównać ich aktywność z deklarowanym zastosowaniem i sprawdzić, czy nadal są potrzebne.

Drugim zadaniem jest przegląd sposobu uwierzytelniania i uprawnień. Microsoft zaleca ograniczanie uprawnień do minimum oraz okresową recertyfikację kont usługowych. Tam, gdzie aplikacja działa w Azure i obsługuje ten model, managed identity pozwala uniknąć zarządzania hasłem użytkownika. W innych scenariuszach właściwym modelem może być service principal lub federacja tożsamości workload.

Trzecim zadaniem jest monitoring. Microsoft wskazuje dzienniki logowania Entra jako źródło do obserwowania kont usługowych, w tym zmian wzorca aktywności. Konto, które przez długi czas nie miało legalnych sesji, a nagle zaczyna korzystać z Teams, OneDrive, SharePoint lub portalu administracyjnego, wymaga szybkiej weryfikacji.

Jak wykorzystać ten przypadek w security awareness

Ta kampania nie zaczęła się od wiadomości phishingowej do pracownika. Dlatego nie jest argumentem, że szkolenie użytkowników zatrzyma każdy incydent tożsamościowy. Pokazuje inną rzecz: program bezpieczeństwa powinien rozróżniać ryzyko ludzkich kont od ryzyka kont technicznych.

Dla pracowników użyteczna lekcja pojawia się po przejęciu. Konto z legalnej domeny organizacji może zostać użyte do dalszej komunikacji, udostępniania plików lub tworzenia wiarygodnego kontekstu dla kolejnego ataku. Zaufanie do samego nadawcy nie powinno zastępować oceny żądanej czynności.

W testach phishingowych dla firm można ćwiczyć właśnie ten etap: wiadomość pochodzi z pozornie właściwego kontekstu, ale odbiorca nadal weryfikuje nietypowe żądanie. Szerszy program security awareness powinien łączyć tę umiejętność z procedurą szybkiego zgłaszania podejrzanej aktywności.

Co wynika z kampanii TeamFiltration

Wynik 7 przejęć na 5714 celów może wyglądać jak mała skuteczność password sprayingu. Z perspektywy obrony wystarczy jednak jedno aktywne konto z dostępem do danych lub aplikacji, aby powstał nowy punkt wejścia.

W opisywanej kampanii wspólnym mianownikiem skutecznych przejęć nie byli pracownicy, lecz konta funkcjonalne i usługowe pozostawione bez właściwego nadzoru. To przesuwa pytanie z „czy użytkownicy mają MFA?” na szersze: czy organizacja zna wszystkie aktywne tożsamości, ich właścicieli, cel, uprawnienia i cykl życia?

TeamFiltration przypomina, że porządek w tożsamościach technicznych jest częścią ochrony Microsoft 365. Inwentaryzacja, właściwy typ workload identity, minimalne uprawnienia, monitoring i usuwanie niepotrzebnych kont ograniczają powierzchnię, której nie da się zabezpieczyć samym szkoleniem pracowników.