Todyl podała, że między 1 a 3 listopada 2026 r. skradzione poświadczenia aplikacji i powiązane artefakty tożsamości zapewniły dostęp do środowisk 27 organizacji. Ta liczba dotyczy organizacji, których środowiska przekazywały logi do Todyl. Firma opisała też pobieranie plików i dostęp do elementów skrzynek pocztowych; według niej w ataku nie wykorzystano luki w zabezpieczeniach Microsoft. Todyl opisała przebieg incydentu i swoje obserwacje.
Todyl odnotowała około 45 zaatakowanych rejestracji aplikacji w mniej więcej 18 organizacjach, z czego ponad 33 skutecznie się uwierzytelniły. Firma podała również, że sprawdzano około 25 tenantów, pobrano 81 plików i uzyskano dostęp do około 2279 elementów skrzynek pocztowych. To wyniki telemetrii Todyl, a nie liczba opisująca wszystkie organizacje objęte kampanią.
Jak przebiegał dostęp według Todyl
Todyl datowała poszczególne etapy na 1–3 listopada 2026 r. Wszystkie godziny podano w UTC.
| Data i godzina (UTC) | Zdarzenie opisane przez Todyl |
| 1 listopada, 08:45 | Pierwszy zaobserwowany dostęp z użyciem skradzionego poświadczenia aplikacji. |
| 1 listopada, 14:39 | Użycie federacyjnej tożsamości obciążenia Azure DevOps z adresu przypisanego operatorowi. |
| 2 listopada, 10:39 | Pierwsze zaobserwowane ponowne użycie tokenu sesji użytkownika Azure DevOps. |
| 2 listopada, 17:40 | Pierwsze wyszukiwanie w Microsoft Graph w środowisku ofiary. |
| 2 listopada, 20:36 | Rozpoczęły się masowe pobrania plików, w tempie około jednego pliku na sekundę. |
| 3 listopada, 07:56 | Aplikacja jednego MSP przeszukiwała środowiska 15 klientów w pętlach trwających około 10 sekund. |
| 3 listopada, 15:16 | Ostatnie zgłoszone przez Todyl udane działanie: pobieranie danych przez aplikację w jednym MSP. |
| 3 listopada, 18:12 | Todyl odnotowała zablokowane przez Conditional Access próby ponownego użycia tokenów odświeżania. |
| 3 listopada, 21:31 | Najpóźniejsza opisana próba została zablokowana. |
Todyl podała, że poświadczenia aplikacji umożliwiały uwierzytelnianie bez interaktywnego logowania pracownika. W obserwowanej sekwencji tokenów pojawiały się Azure Resource Manager i Key Vault, a następnie często Microsoft Graph, Storage i Cognitive Services. Todyl uznała, że odczyty z Key Vault mogły dostarczyć kolejnych poświadczeń; do potwierdzenia tej zależności potrzebne są logi audytowe.
Dlaczego tożsamości aplikacji wymagają osobnej kontroli
Uwierzytelnianie app-only pozwala aplikacji logować się bez udziału człowieka. Dlatego polityka skoncentrowana na interaktywnych logowaniach użytkowników nie obejmuje automatycznie takich połączeń. Todyl opisała około 95% zaobserwowanych logowań jako wykonywane przez skrypty; w krótkich seriach odnotowano do 24 logowań w ciągu 10 sekund.
Według Todyl polityki Conditional Access dla tożsamości obciążeń wymagają samodzielnej licencji Workload ID Premium i bezpośredniego przypisania do service principal. Przypisanie przez grupę nie jest dla nich egzekwowane. Opisany zakres obejmuje aplikacje jednokrotnego dzierżawcy zarejestrowane w danym tenantcie, a nie obejmuje tożsamości zarządzanych, aplikacji wielodostępnych ani usług SaaS firm trzecich.
Co administratorzy mogą sprawdzić
Todyl wskazała adres 199.19.77.84 jako potwierdzony adres operatora i zaleciła blokowanie właśnie tego adresu, a nie szerszej sieci hostingowej. Firma podała też, że 3 listopada Conditional Access zablokował wiele prób ponownego użycia tokenów odświeżania. W monitorowanym przez nią okresie nie zaobserwowano nowych zgód, poświadczeń, ról ani użytkowników wskazujących na utrzymanie dostępu.
W ocenie własnego środowiska administratorzy powinni uwzględnić logowania aplikacji i service principals, a także sprawdzić logi audytowe dotyczące odczytów Key Vault. Todyl nie ustaliła, jak zdobyto pierwotne poświadczenia ani kto obsługiwał kampanię.
