Microsoft ujawnia trzy ścieżki ataków na Salesforce powiązane z aktywnością ShinyHunters

Co znajdziesz w tym artykule?

1 Wprowadzenie do problemu / definicja
2 W skrócie
3 Kontekst / historia
4 Analiza techniczna
5 Konsekwencje / ryzyko
6 Rekomendacje
7 Podsumowanie
8 Źródła

Wprowadzenie do problemu / definicja

Microsoft opisał trzy główne ścieżki ataków wymierzonych w środowiska Salesforce, które były powiązane z aktywnością przypisywaną ekosystemowi ShinyHunters. Kluczowe jest to, że napastnicy nie musieli wykorzystywać klasycznych podatności samej platformy. Zamiast tego nadużywali zaufanych integracji, tokenów OAuth oraz błędnych konfiguracji dostępu gościnnego.

To ważny sygnał dla zespołów bezpieczeństwa, ponieważ pokazuje, że nowoczesna powierzchnia ataku w środowiskach SaaS obejmuje nie tylko aplikację główną, ale także połączone usługi, konta integracyjne oraz relacje z zewnętrznymi dostawcami.

W skrócie

Microsoft zidentyfikował trzy dominujące wektory ataku na organizacje korzystające z Salesforce.
Pierwszy scenariusz opiera się na vishingu i nakłanianiu użytkowników do autoryzacji złośliwej aplikacji OAuth.
Drugi dotyczy przejęcia tokenów OAuth od zaufanych dostawców zewnętrznych mających dostęp do środowisk klientów.
Trzeci wykorzystuje nadmierne uprawnienia użytkowników gościnnych w publicznych komponentach Experience Cloud.
Wspólnym elementem wszystkich metod jest omijanie tradycyjnych mechanizmów detekcji opartych na logowaniach i standardowym uwierzytelnianiu.

Kontekst / historia

Z ustaleń Microsoftu wynika, że kampanie były obserwowane przez około rok, od połowy 2025 do połowy 2026 roku, i dotyczyły organizacji z wielu sektorów, między innymi handlu, edukacji oraz produkcji. Aktywność ta wpisuje się w szerszy trend operacji związanych z grupami i afiliantami kojarzonymi z ShinyHunters, które wielokrotnie pojawiały się w incydentach obejmujących kradzież danych i wymuszenia.

W pierwszej fazie opisywane działania przypominały znane już kampanie socjotechniczne, w których przestępcy podszywali się pod wsparcie IT i telefonicznie prowadzili ofiary przez proces akceptacji dostępu dla aplikacji OAuth. Z czasem model ten rozszerzył się o kompromitację dostawców trzecich, którzy posiadali już autoryzowany dostęp do tenantów klientów. Równolegle ujawniono też ryzyko związane z błędną konfiguracją publicznych interfejsów Experience Cloud.

Analiza techniczna

Pierwsza ścieżka ataku polegała na wykorzystaniu mechanizmu zgody OAuth. Napastnicy wykonywali połączenia vishingowe, podszywając się pod dział IT, a następnie nakłaniali użytkowników do zatwierdzenia złośliwej aplikacji połączonej. Po przyznaniu zgody aplikacja uzyskiwała możliwość wykonywania wywołań API w kontekście ofiary, co mogło prowadzić do trwałego dostępu do danych CRM, enumeracji zasobów oraz dalszego ruchu bocznego do innych usług SaaS.

Drugi wariant był bardziej niebezpieczny operacyjnie, ponieważ nie wymagał bezpośredniego zaangażowania użytkownika końcowego. Atakujący kompromitowali zaufanego dostawcę zewnętrznego, którego aplikacja posiadała już autoryzowany dostęp OAuth do środowisk klientów. Kradzież tokenów dostępu lub tokenów odświeżania pozwalała na odpytywanie wielu instancji klientów i eksport danych w sposób, który z perspektywy monitoringu wyglądał jak legalna aktywność znanej integracji.

Trzecia ścieżka dotyczyła Salesforce Experience Cloud i komponentów korzystających z endpointów Aura. Jeżeli uprawnienia użytkowników gościnnych były skonfigurowane zbyt szeroko, możliwe stawało się wykonywanie operacji odczytu bez uwierzytelnienia. Microsoft wskazał również na wykorzystywanie mechanizmów paginacji kursorem do pobierania większej liczby rekordów, niż mogłyby sugerować standardowe ograniczenia zapytań.

Najważniejszy wniosek techniczny jest taki, że tradycyjne logi uwierzytelnienia nie zapewniają dziś pełnej widoczności. Jeżeli dostęp odbywa się przez autoryzowaną aplikację, konto usługowe lub prawidłowo uwierzytelnioną integrację partnera, detekcja musi koncentrować się na analizie zachowania po uzyskaniu dostępu, w tym zakresów OAuth, wzorców zapytań API, wolumenu eksportu danych i odchyleń od normalnej aktywności w tenantcie.

Konsekwencje / ryzyko

Ryzyko dla organizacji jest istotne i wielowarstwowe. Najbardziej bezpośrednim skutkiem może być nieautoryzowany dostęp do danych klientów, rekordów CRM, historii zgłoszeń, metadanych biznesowych oraz innych wrażliwych informacji przechowywanych w środowisku Salesforce. W zależności od sposobu wykorzystania pozyskanych danych incydent może prowadzić także do dalszej eskalacji w innych usługach chmurowych.

Szczególnie narażone są firmy silnie uzależnione od rozbudowanego ekosystemu integracji SaaS. Każda dodatkowa aplikacja połączona zwiększa powierzchnię ataku, a kompromitacja jednego partnera może przełożyć się na dostęp do wielu środowisk klientów jednocześnie. To forma ataku supply chain realizowanego nie przez złośliwą aktualizację, lecz przez nadużycie istniejącego zaufania i relacji OAuth.

Nie można też pomijać skutków reputacyjnych i regulacyjnych. Dane gromadzone w systemach CRM często obejmują informacje kontaktowe, historię relacji handlowych i dane operacyjne, które mogą podlegać obowiązkom zgłoszeniowym oraz sankcjom wynikającym z przepisów o ochronie danych. Dodatkowym problemem jest możliwość opóźnionego wykrycia incydentu, ponieważ ruch generowany przez legalnie wyglądające integracje może przez długi czas nie wzbudzać podejrzeń.

Rekomendacje

Organizacje korzystające z Salesforce powinny traktować aplikacje połączone OAuth i integracje zewnętrzne jako krytyczny element bezpieczeństwa tożsamościowego. Należy zbudować pełny rejestr aplikacji połączonych, kont usługowych i dostawców zewnętrznych wraz z zakresem uprawnień, właścicielem biznesowym oraz informacją o ostatnim użyciu. Nieużywane lub osierocone integracje powinny zostać wyłączone.

Ograniczyć zakresy OAuth zgodnie z zasadą najmniejszych uprawnień.
Regularnie przeglądać i zatwierdzać połączone aplikacje oraz ich uprawnienia.
Wdrożyć monitoring telemetrii API, identyfikatorów aplikacji i nietypowych eksportów danych.
Rotować sekrety oraz szybko unieważniać tokeny po wykryciu anomalii.
Przeszkolić pracowników w zakresie ochrony przed vishingiem i fałszywymi żądaniami autoryzacji.
Przeprowadzić audyt uprawnień gościnnych i publicznych endpointów Experience Cloud.
Przygotować procedury reagowania na incydenty związane z kompromitacją dostawcy trzeciego.

Z perspektywy zespołów SOC kluczowe jest rozszerzenie detekcji poza klasyczne logi logowania. Analiza powinna obejmować zachowanie aplikacji, zmiany w przyznanych scope’ach, nietypowe zapytania oraz nagłe wzrosty wolumenu odczytu danych. W przypadku środowisk publicznych należy potraktować zbyt szerokie uprawnienia gościnne jako krytyczne ryzyko konfiguracyjne.

Podsumowanie

Opisane przez Microsoft kampanie pokazują, że ataki na środowiska SaaS coraz częściej omijają tradycyjny model włamania oparty na exploicie lub przejęciu hasła. Zamiast tego przestępcy wykorzystują to, co organizacje same uznały za zaufane: aplikacje połączone, integracje partnerów i publicznie dostępne komponenty.

Dla użytkowników Salesforce oznacza to konieczność przesunięcia uwagi z samego uwierzytelniania na całościowy nadzór nad relacjami OAuth, zachowaniem aplikacji oraz konfiguracją uprawnień. Brak widoczności i kontroli nad zaufanymi integracjami może dziś stanowić zagrożenie równie poważne jak niezałatana podatność.