Atak na Entra ID i Azure DevOps przez poświadczenia aplikacji

Zespół Todyl MXDR opisuje trwającą kampanię, w której napastnik loguje się do Microsoft Entra ID i Azure DevOps jako legalne aplikacje, używając skradzionych, nadal ważnych poświadczeń. Od 1 listopada zaatakowano około 45 rejestracji aplikacji w mniej więcej 18 organizacjach, a ponad 33 uwierzytelniły się skutecznie. Dostęp objął dotąd 27 organizacji, w tym klientów dostawców MSP.

To ważne ostrzeżenie dla firm, ponieważ atak nie musi generować prośby o MFA ani alarmu typowego dla przejęcia konta pracownika. Ważny sekret aplikacji pozwala usłudze zalogować się zgodnie z przeznaczeniem technicznym, a reguły Conditional Access skierowane tylko do użytkowników nie muszą mieć zastosowania.

Najważniejsze działanie: sprawdź logowania service principals i Azure DevOps z adresu 199[.]19[.]77[.]84, ale nie ograniczaj analizy do jednego wskaźnika. Szukaj aplikacji łączących się w krótkim czasie z Azure Resource Manager, Key Vault, Storage i Microsoft Graph, nieoczekiwanych pobrań oraz sekwencji nieudanego i udanego logowania tym samym sekretem.

Co wiemy o kampanii

Według aktualizacji Todyl z 3 listopada jeden operator korzysta z wcześniej skradzionego zbioru sekretów aplikacji. Z 45 atakowanych rejestracji w około 18 organizacjach ponad 33 zalogowały się skutecznie. Przez relacje MSP i delegowaną administrację napastnik dotarł do 27 organizacji z sektorów obejmujących administrację, energetykę, żywność i rolnictwo, transport, budownictwo, usługi prawne, edukację i organizacje non-profit.

W danych widocznych dla Todyl operator prowadził wyszukiwania w około 25 tenantach, pobrał 81 plików i uzyskał dostęp do około 2279 elementów skrzynek pocztowych. Liczby te są dolnym oszacowaniem, ponieważ obejmują tylko środowiska wysyłające logi do firmy.

Nie ma informacji o podatności w Microsoft Entra ID. Atak wykorzystuje ważne poświadczenia, niewłaściwie szerokie uprawnienia i zaufane relacje. Nie ma też potwierdzenia, w jaki sposób początkowy zbiór sekretów został skradziony ani kto stoi za kampanią.

Dlaczego atak wygląda jak robak, choć nim nie jest

Aktywność jest bardzo szybka. W jednym przypadku po pobraniu archiwum konektora napastnik użył poświadczeń powiązanej aplikacji po około 2,5 minuty. Skrypty wykonywały do 24 logowań w 10 sekund, a jedna wielodostępna aplikacja przeszła przez 15 tenantów klientów w krótkich pętlach.

Todyl ocenia jednak, że nie jest to samodzielnie rozprzestrzeniający się kod. Luki czasowe, zmiany user-agentów po uruchomieniu detekcji i ponowne próby wskazują na człowieka sterującego automatyzacją. Możliwe użycie narzędzi agentowych lub wsparcia AI ma niski poziom pewności; telemetria nie pokazuje konkretnego modelu kierującego operacją.

To rozróżnienie ma znaczenie. Organizacja nie powinna publikować niepotwierdzonej tezy o „robaku AI”. Powinna natomiast reagować na potwierdzone zachowania: kradzież poświadczeń workload identities, automatyczne przeszukiwanie zasobów i szybkie przechodzenie przez relacje dostawca–klient.

Jak napastnik wykorzystuje legalne tożsamości

Service principal reprezentuje aplikację działającą w danym tenancie. Może używać sekretu klienta, certyfikatu albo federacyjnego poświadczenia workload identity. Po udanym uwierzytelnieniu otrzymuje token i wykonuje operacje zgodne z przyznanymi uprawnieniami — często bez interaktywnego użytkownika i bez MFA.

W obserwowanej kampanii napastnik kierował żądania do Azure Resource Manager, Key Vault, Storage, Microsoft Graph i, gdy było dostępne, Partner Center. Użyto także federacyjnej tożsamości powiązanej z Azure DevOps oraz odtworzono sesje dwóch użytkowników Azure DevOps.

Skradziony sekret jednej aplikacji może otworzyć dostęp do kolejnych sekretów w Key Vault, dokumentacji klientów, kodu źródłowego i połączeń wdrożeniowych. U dostawcy MSP skutek rośnie przez delegated admin i relacje GDAP: jedna tożsamość może prowadzić do wielu tenantów klientów.

Plan reakcji na dziś

1. Zabezpiecz logi przed ich utratą

Eksportuj logi logowania service principals, nieinteraktywnych logowań użytkowników, audytu Entra, Microsoft 365, Azure Activity, Key Vault, Storage i Azure DevOps. Retencja może być krótka, a dane są potrzebne do oceny dostępu i obowiązków zgłoszeniowych.

2. Wyszukaj potwierdzony wskaźnik i zachowania

Sprawdź adres 199[.]19[.]77[.]84, ale nie blokuj całego ASN — Todyl wyraźnie ostrzega, że inne adresy tej sieci wykonują niezwiązaną aktywność. Szukaj też jednego źródła logującego się do wielu service principals, mieszanki błędów i sukcesów oraz szybkiego przechodzenia jednej aplikacji przez ARM, Key Vault, Storage i Graph.

Błąd AADSTS7000215 może oznaczać próbę użycia nieprawidłowego sekretu, a AADSTS7000222 — sekretu wygasłego. Nieudane logowanie, po którym ten sam App ID loguje się skutecznie z tego samego źródła, powinno być pilnie zbadane.

3. Ogranicz dostęp i unieważnij poświadczenia

Dla dotkniętej aplikacji usuń sekrety, certyfikaty i federacyjne poświadczenia, których nie potrafisz jednoznacznie zatwierdzić. W razie potrzeby wyłącz service principal. Unieważnij sesje użytkowników, PAT-y Azure DevOps i klucze SSH związane z incydentem. Pamiętaj, że wydane tokeny mogą działać do wygaśnięcia.

4. Ustal zasięg danych

Przejrzyj role katalogowe i Azure RBAC, uprawnienia API, dostęp do Key Vault, Partner Center, repozytoriów i service connections. Zidentyfikuj pobrane pliki, zapytania do skrzynek, odczytane sekrety i uruchomione pipeline’y. Jeżeli aplikacja mogła odczytać vault lub dokument z hasłami, rotuj również poświadczenia niższego poziomu.

5. W przypadku MSP sprawdź klientów

Nie kończ analizy na własnym tenancie. Zweryfikuj relacje GDAP, aplikacje wielodostępne i działania w tenantach klientów. Uruchom proces powiadomień zgodnie z umowami i przepisami, gdy potwierdzisz dostęp lub nie możesz wykluczyć ekspozycji danych.

Jak ograniczyć całą klasę ryzyka

Preferuj managed identities, następnie workload identity federation, a dopiero później certyfikaty przechowywane w bezpiecznym magazynie. Długowieczne client secrets powinny być wyjątkiem. Federacja usuwa zapisany sekret, ale przenosi zaufanie do systemu wydającego token, dlatego Azure DevOps musi mieć równie silne zabezpieczenia.

Ogranicz uprawnienia aplikacji, przypisz właścicieli, ustaw maksymalny czas życia credentiali i regularnie usuwaj nieużywane service principals. Dostęp do Key Vault i Storage ogranicz prywatnymi endpointami lub wybranymi sieciami, aby sam poprawny token nie wystarczał z dowolnego miejsca.

Conditional Access dla workload identities ma ograniczenia licencyjne i zakresowe. Nie obejmuje każdej managed identity, aplikacji wielodostępnej ani zewnętrznego SaaS. Dlatego nie można sprowadzić obrony do jednej polityki. Potrzebne są minimalne uprawnienia, logowanie, detekcja behawioralna i kontrola systemów, w których sekret mógł się znaleźć.

Więcej o ocenie tego obszaru opisujemy w przewodniku pentest Microsoft Entra ID.

Fakty źródłowe i wnioski Breachroad

Todyl potwierdza aktywną kampanię, liczbę obserwowanych aplikacji i organizacji, użycie adresu 199[.]19[.]77[.]84, dostęp do zasobów Microsoft 365 i Azure oraz konkretne rekomendacje detekcji i containmentu. Źródło podkreśla, że nie ma luki w Microsoft, nie ustalono sprawcy ani początkowego źródła sekretów, a rola AI pozostaje hipotezą o niskiej pewności.

Priorytet dla zabezpieczenia logów, udział zespołów prawnych i prywatności, przegląd obowiązków dostawcy MSP oraz ćwiczenie decyzji biznesowych są rekomendacjami Breachroad. Firmy mogą przygotować administratorów, helpdesk i właścicieli usług podczas szkoleń cyberbezpieczeństwa dla organizacji. Uprawnienia aplikacji i widoczność logów może zweryfikować audyt bezpieczeństwa IT.

FAQ: kampania przeciw Entra ID i Azure DevOps

Czy to podatność Microsoft Entra ID?

Nie. Według dostępnych danych napastnik używa prawidłowych, wcześniej skradzionych poświadczeń aplikacji i sesji. Problem dotyczy kontroli sekretów, uprawnień i monitoringu.

Czy MFA zatrzyma taki atak?

MFA użytkownika nie jest wywoływane przy zwykłym logowaniu aplikacji. Potrzebne są polityki dla workload identities, ograniczenia sieciowe, minimalne uprawnienia i monitoring logowań service principals.

Czy wystarczy zablokować jeden adres IP?

Nie. To szybkie działanie ograniczające, ale infrastruktura może się zmienić. Należy wyszukiwać zachowania, rotować poświadczenia i ustalić, do jakich zasobów aplikacja miała dostęp.

Czy atak został przypisany konkretnej grupie?

Nie. Todyl określa aktywność jako nieprzypisaną i ocenia ją jako niezwiązaną z październikowym incydentem ConnectWise Cloud Backup przypisanym Storm-0940.

Źródła pierwotne: Todyl — Stolen App Credentials, Real Access, Microsoft Learn — Conditional Access for workload identities, Microsoft Learn — Azure DevOps auditing.