Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Nowo opisana kampania cybernetyczna pokazuje, że współcześni napastnicy coraz częściej rezygnują z klasycznej kradzieży haseł na rzecz przejmowania już uwierzytelnionych sesji użytkowników. Malware Umbrij, powiązany z grupą ToddyCat, został zaprojektowany do uzyskiwania dostępu do firmowej poczty Gmail poprzez przejęcie tokenów OAuth i wykorzystanie oficjalnych interfejsów Google API.
To podejście jest szczególnie niebezpieczne, ponieważ omija część tradycyjnych mechanizmów ochronnych opartych na haśle i samym procesie logowania. Jeżeli użytkownik ma aktywną sesję Google w przeglądarce, a stacja robocza zostanie skompromitowana, atakujący może wykorzystać istniejący stan uwierzytelnienia do dalszej eskalacji dostępu.
W skrócie
Umbrij to narzędzie wykorzystywane w kampanii cyberwywiadowczej wymierzonej w konta Gmail w środowiskach korporacyjnych. Malware uruchamia przeglądarkę Chromium w trybie headless, korzysta z portu zdalnego debugowania i automatyzuje proces uzyskania kodu autoryzacyjnego OAuth.
- celem ataku są konta Gmail w organizacjach korzystających z Google Workspace,
- malware bazuje na aktywnej sesji użytkownika w przeglądarce,
- po uzyskaniu kodu OAuth napastnicy mogą wymienić go na token dostępu,
- dostęp może objąć nie tylko Gmail, ale również Dysk, Kontakty, Kalendarz i Zadania,
- cała operacja wykorzystuje legalne mechanizmy Google API, co utrudnia wykrycie.
Kontekst / historia
Grupa ToddyCat jest od lat łączona z zaawansowanymi operacjami APT ukierunkowanymi na organizacje w Europie i Azji. Wcześniejsze działania tej grupy koncentrowały się między innymi na przejmowaniu danych pocztowych oraz aktywności w środowiskach biznesowych, gdzie poczta elektroniczna stanowi kluczowe źródło informacji operacyjnych i strategicznych.
Najnowsza kampania wskazuje na wyraźną ewolucję technik. Zamiast ograniczać się do bezpośredniego wykradania wiadomości z klienta pocztowego, napastnicy skupiają się na warstwie tożsamości, sesji oraz autoryzacji w usługach chmurowych. Taki model działania lepiej wpisuje się w realia nowoczesnych środowisk pracy, gdzie dostęp do poczty i dokumentów jest silnie powiązany z przeglądarką i usługami SaaS.
Według opisu incydentu Umbrij został wykryty podczas działań threat hunting. Malware miał być uruchamiany za pomocą zaplanowanego zadania podszywającego się pod legalny komponent bezpieczeństwa, a następnie korzystał z techniki DLL side-loading z użyciem podpisanych plików wykonywalnych, co utrudniało detekcję oraz zwiększało wiarygodność procesu.
Analiza techniczna
Rdzeń ataku opiera się na połączeniu kilku technik: przejęcia kontekstu bezpieczeństwa użytkownika, analizy profilu przeglądarki, uruchomienia przeglądarki w trybie headless oraz nadużycia procesu OAuth 2.0. Umbrij działa na systemach Windows i wykorzystuje lokalne artefakty przeglądarek Chrome lub Edge do odtworzenia sesji użytkownika.
Po uruchomieniu malware wykonuje czynności przygotowawcze. Sprawdza dostępność portu debugowania, identyfikuje proces explorer.exe i duplikuje token użytkownika, aby działać w kontekście zalogowanej osoby. Następnie analizuje plik Local State i inne dane profilu przeglądarki w celu ustalenia, czy w systemie znajduje się aktywne konto Google.
Kolejny etap polega na kopiowaniu wybranych artefaktów profilu do katalogu roboczego. Obejmuje to między innymi dane IndexedDB, Local Storage, ustawienia sieciowe, bazy logowania i preferencje przeglądarki. Jeżeli pliki są zablokowane przez działające procesy, malware stosuje mechanizmy wymuszonego kopiowania, aby pozyskać potrzebne dane.
Następnie Umbrij uruchamia Chrome lub Edge w trybie headless, wskazując skopiowany profil oraz aktywując zdalne debugowanie. Dzięki temu może sterować przeglądarką bez udziału użytkownika. Do automatyzacji używana jest biblioteka Puppeteer oraz protokół Chrome DevTools Protocol, co pozwala precyzyjnie odtworzyć sekwencję działań potrzebnych do przejścia procesu autoryzacyjnego.
Kluczowy moment operacji następuje podczas wygenerowania żądania autoryzacyjnego OAuth do usług Google. Malware kieruje przeglądarkę na odpowiedni punkt autoryzacji, wykorzystując identyfikator klienta przypisany do narzędzia migracyjnego dla środowisk Google Workspace. Następnie automatyzuje wybór konta oraz akceptację żądanych uprawnień.
Po uzyskaniu zgody przeglądarka zostaje przekierowana na lokalny adres, z którego Umbrij odczytuje kod autoryzacyjny OAuth. Kod ten może zostać zapisany w logach i wyeksfiltrowany, a następnie wymieniony na token dostępu umożliwiający komunikację z zasobami ofiary przez Google API. W praktyce oznacza to, że napastnik nie musi przełamywać zabezpieczeń logowania w tradycyjny sposób, ponieważ korzysta z już uwierzytelnionej sesji.
Dodatkowym elementem utrudniającym analizę jest sposób dostarczania ładunku. Opisane próbki wykorzystywały legalne binaria podatne na DLL side-loading, pochodzące między innymi z oprogramowania bezpieczeństwa, Visual Studio oraz starszych narzędzi Google. Sam Umbrij był implementowany jako biblioteka .NET i dodatkowo zaciemniany, co ogranicza skuteczność analizy statycznej.
Konsekwencje / ryzyko
Ryzyko związane z Umbrij należy ocenić jako wysokie, ponieważ atak łączy kompromitację stacji roboczej z uzyskaniem trwałego i skalowalnego dostępu do zasobów chmurowych. Wykorzystanie oficjalnych API sprawia, że aktywność napastnika może wyglądać mniej podejrzanie niż klasyczne próby logowania lub masowy eksport wiadomości przez interfejs webowy.
Najpoważniejszą konsekwencją jest przejęcie korespondencji firmowej. Dostęp do Gmaila może prowadzić do wycieku informacji strategicznych, danych klientów, materiałów prawnych, dokumentów transakcyjnych oraz komunikacji kierownictwa. Jeżeli zakres zgody OAuth obejmuje także inne usługi Google, atakujący zyskuje szerszy wgląd w działalność organizacji, relacje biznesowe i kalendarze działań.
Z perspektywy obrony szczególnie niepokojące jest to, że atak nie musi wiązać się z kradzieżą hasła ani klasycznym obejściem MFA. Wystarczy aktywna sesja użytkownika w przeglądarce i lokalna kompromitacja endpointu. To oznacza, że bezpieczeństwo kont chmurowych jest dziś bezpośrednio zależne od integralności stacji roboczej, przeglądarki oraz kontroli nad tokenami i zgodami aplikacyjnymi.
Rekomendacje
Organizacje korzystające z Gmaila i Google Workspace powinny traktować ten scenariusz jako przykład ataku na sesję, tokeny OAuth i warstwę przeglądarki, a nie wyłącznie na poświadczenia. Skuteczna obrona wymaga połączenia telemetrii endpointowej, monitoringu usług chmurowych oraz kontroli aplikacji zewnętrznych.
- przeprowadzić audyt aplikacji mających dostęp do kont Google użytkowników,
- cofnąć nieautoryzowane lub zbędne zgody OAuth,
- monitorować uruchamianie Chrome i Edge z parametrami headless oraz remote debugging,
- wykrywać kopiowanie artefaktów profilu przeglądarki, takich jak Local State, Login Data, Web Data, IndexedDB i Local Storage,
- wdrożyć detekcje dla DLL side-loading z użyciem podpisanych binariów uruchamianych z nietypowych lokalizacji,
- ograniczyć możliwość lokalnego uruchamiania niezatwierdzonych narzędzi poprzez mechanizmy allowlistingu,
- regularnie analizować logi API, zdarzenia consent grant i alerty dotyczące dostępu do danych pocztowych w Google Workspace.
W przypadku podejrzenia kompromitacji należy natychmiast odizolować stację roboczą od sieci, unieważnić podejrzane tokeny, cofnąć zgody OAuth, przeanalizować historię dostępu do Gmail API i innych usług Google oraz wymusić ponowne logowanie użytkownika. Konieczne jest także sprawdzenie mechanizmów trwałości, takich jak harmonogram zadań, autostart i artefakty przeglądarki.
Podsumowanie
Kampania wykorzystująca Umbrij pokazuje wyraźny trend w cyberwywiadzie: przejęcie sesji i nadużycie mechanizmów autoryzacji staje się równie skuteczne jak klasyczna kradzież danych logowania. W praktyce atakujący mogą uzyskać cichy dostęp do Gmaila i powiązanych usług przez oficjalne interfejsy API, znacząco utrudniając wykrycie incydentu.
Dla zespołów bezpieczeństwa to jasny sygnał, że ochrona tożsamości w chmurze musi obejmować cały łańcuch zależności: endpoint, przeglądarkę, tokeny, zgody aplikacyjne i monitoring aktywności API. Bez takiego podejścia nawet silne uwierzytelnianie może nie wystarczyć do zatrzymania podobnych operacji.
Źródła
- The Hacker News — ToddyCat-Linked Umbrij Malware Abuses OAuth to Access Gmail via Google API — https://thehackernews.com/2026/07/toddycat-linked-umbrij-malware-abuses.html
- Securelist — ToddyCat’s new tool automates Gmail access via OAuth abuse — https://securelist.com/
- Google for Developers — Headless mode in Chromium-based browsers — https://developer.chrome.com/
- Puppeteer Documentation — Browser automation over Chrome DevTools Protocol — https://pptr.dev/
- Chromium Documentation — User data and browser profile structure — https://chromium.googlesource.com/