Atakujący, których metody pokrywają się z działaniami grupy wymuszającej okup za dane ShinyHunters, przez ostatni rok atakowali firmowe środowiska Salesforce bez wykorzystywania podatności w samym Salesforce.
Zamiast tego kampanie nadużywały czegoś, na czym wiele organizacji polega na co dzień: zaufanych połączeń OAuth, połączonych aplikacji, integracji firm trzecich i błędnie skonfigurowanego dostępu gościa.
Microsoft podaje, że aktywność trwała od połowy 2025 do połowy 2026 roku i dotknęła organizacje z różnych branż, w tym handlu detalicznego, edukacji i produkcji.
Sedno problemu nie leży w zepsutej platformie Salesforce. To warstwa zaufania wokół Salesforce.
Dlaczego trudno to wykryć
Wiele programów bezpieczeństwa opiera się na logowaniach użytkowników.
Monitorują one logowania, nieudane próby MFA, podejrzane adresy IP, niemożliwe podróże i ataki oparte na hasłach.
Jednak w tych kampaniach przeciwko Salesforce dostęp często uzyskiwano za pośrednictwem czegoś, co już wyglądało na legalne:
- prawdziwego użytkownika zatwierdzającego aplikację OAuth
- zaufanej integracji dostawcy
- istniejącego połączenia usługowego
- błędnie skonfigurowanej roli gościa
Oznacza to, że tradycyjne logi uwierzytelniania mogą pokazywać bardzo niewiele.
Atakujący nie musi się włamywać za pomocą malware ani skradzionych haseł, jeśli może sprawić, że zatwierdzona aplikacja lub zaufana integracja będzie wykonywać wywołania API w jego imieniu.
Ważny sygnał to nie tylko kto się zalogował.
To co połączona aplikacja zrobiła po przyznaniu dostępu.
Microsoft zidentyfikował trzy główne ścieżki włamania
Microsoft pogrupował aktywność w trzy techniki:
- połączenia vishingowe, które nakłaniają pracowników do zatwierdzania złośliwych połączonych aplikacji
- skradzione tokeny OAuth od przejętych dostawców oprogramowania
- błędnie skonfigurowany dostęp gościa do Salesforce w witrynach Experience Cloud
Każda technika nadużywa zaufania w inny sposób.
Razem pokazują, że ryzyko związane z Salesforce coraz częściej leży wokół platformy: w integracjach, u dostawców, w uprawnieniach i w wyeksponowanych procesach biznesowych.
1️⃣ Ścieżka pierwsza: vishing i złośliwa zgoda OAuth
Pierwsza technika opierała się na phishingu głosowym.
Atakujący dzwonili do pracowników, podszywając się pod wsparcie IT, i przeprowadzali ich przez ekran zgody OAuth w Salesforce.
Celem było nakłonienie ofiary do zatwierdzenia kontrolowanej przez atakującego połączonej aplikacji podszywającej się pod własne narzędzie Salesforce Data Loader.
Gdy użytkownik zatwierdził aplikację, atakujący mogli wykonywać wywołania API jako ten użytkownik.
Taki dostęp mógł pozwolić im wyliczać dane w Salesforce, utrzymywać dostęp do rekordów CRM oraz szukać poświadczeń lub sekretów, które mogłyby otworzyć dostęp do innych środowisk SaaS.
Nie potrzebowali odtwarzania haseł.
Nie potrzebowali malware.
Atak się powiódł, ponieważ prawdziwy użytkownik zatwierdził złośliwą aplikację.
Dlatego szkolenia użytkowników i procedury helpdesku mają szczególne znaczenie. Gdy atakujący prowadzą kogoś przez proces autoryzacji podczas rozmowy telefonicznej, zwykłe kontrole tożsamości mogą nie wystarczyć.
2️⃣ Ścieżka druga: skradzione tokeny OAuth od zaufanych dostawców
Druga technika całkowicie omijała pracownika.
Zamiast oszukiwać użytkownika, atakujący przejmowali dostawcę oprogramowania, którego aplikacja miała już dostęp OAuth do środowisk Salesforce klientów.
Następnie kradli tokeny OAuth lub sekrety połączeń i używali ich do wyszukiwania i eksportowania danych z podrzędnych instancji Salesforce.
Jest to szczególnie niebezpieczne, ponieważ ruch pochodzi z zatwierdzonej integracji.
Dla wielu systemów wygląda to jak zwykła automatyzacja.
Microsoft wskazuje na incydenty dotyczące dostawców takich jak Salesloft Drift, Gainsight i Klue.
W przypadku Salesloft Drift atakujący podobno używali skradzionych tokenów OAuth i odświeżania powiązanych z integracją czatu AI Drift, aby uzyskać dostęp do środowisk Salesforce klientów. Operatorzy interesowali się sekretami i poświadczeniami w danych Salesforce, w tym zgłoszeniami wsparcia i innymi obiektami, które mogły zawierać klucze AWS, tokeny Snowflake, hasła lub podobne wrażliwe materiały.
Incydent Gainsight przebiegał według podobnego schematu wobec ekosystemu innego zaufanego dostawcy.
Przejęcie Klue obejmowało od dawna nieużywane, ale wciąż aktywne starsze poświadczenie z integracji testowej. Atakujący użyli go, aby uzyskać dostęp do infrastruktury Klue, wgrać kod zbierający tokeny OAuth klientów, a następnie dotrzeć do danych Salesforce i Gong należących do klientów Klue.
Wniosek jest jasny: stare poświadczenia i integracje dostawców mogą pozostawać niebezpieczne długo po tym, jak zespoły zapomną o ich istnieniu.
3️⃣ Ścieżka trzecia: błędnie skonfigurowany dostęp gościa
Trzecia ścieżka w ogóle nie wymagała poświadczeń.
Microsoft zaobserwował podejrzaną aktywność wymierzoną w punkty końcowe Salesforce Aura używane przez witryny Experience Cloud.
Tam, gdzie uprawnienia użytkownika-gościa były błędnie skonfigurowane, atakujący mogli uzyskać dostęp do funkcji bez uwierzytelniania.
Używali kontrolera GraphQL Aura i stronicowania opartego na kursorze, aby pobierać rekordy poza normalnymi limitami zapytań.
Nie był to exploit.
Było to nadużycie uprawnień.
Rola gościa miała dostęp do większej ilości danych, niż powinna, a atakujący wykorzystali ten dostęp na dużą skalę.
Dla obrońców potwierdza to prostą zasadę: publicznie dostępne witryny Salesforce trzeba dokładnie przeglądać. Użytkownicy-goście powinni mieć absolutne minimum wymaganych uprawnień, a każdy wyeksponowany obiekt należy traktować jak dostępny z Internetu.
Co dodały Microsoft i Salesforce
Microsoft współpracował z Salesforce nad poprawą wykrywania i nadzoru nad tego typu aktywnością.
Nacisk położono na to, co dzieje się po przyznaniu dostępu.
Dla organizacji korzystających z Salesforce Shield Event Monitoring ulepszony konektor Salesforce w Defender for Cloud Apps może zapewnić więcej kontekstu dotyczącego aktywności połączonych aplikacji, zakresów OAuth, szczegółów sesji i zachowania API.
Ma to znaczenie, ponieważ obrońcy muszą wiedzieć:
- która połączona aplikacja wykonała wywołanie
- jakie zakresy OAuth ma aplikacja
- ile danych pobrała w zapytaniach
- czy takie zachowanie jest normalne
- czy aplikacja jest nadal aktywnie używana
- czy aplikacja ma nadmiarowe uprawnienia
Microsoft dodał też funkcje nadzoru (governance), które wskazują aplikacje o wysokich uprawnieniach, nieużywane aplikacje wciąż zachowujące uprawnienia oraz ocenę ryzyka na poziomie aplikacji.
Celem jest znajdowanie ryzykownych integracji, zanim zrobią to atakujący.
Dlaczego OAuth jest dziś główną powierzchnią ataku
OAuth jest niezbędny we współczesnych środowiskach SaaS.
Pozwala aplikacjom łączyć się, automatyzować procesy i uzyskiwać dostęp do danych bez wielokrotnego pytania użytkowników o hasła.
Ta wygoda jednak rodzi ryzyko.
Aplikacje OAuth mogą mieć potężne uprawnienia. Tokeny odświeżania mogą utrzymywać dostęp przy życiu. Integracje usługowe mogą działać po cichu w tle przez lata. Dostawcy mogą mieć dostęp do setek środowisk klientów.
Jeśli te połączenia nie są inwentaryzowane, monitorowane i objęte nadzorem, stają się idealną ścieżką dla atakujących.
Problemem nie jest sam OAuth.
Problemem jest niekontrolowane zaufanie.
Co powinni zrobić obrońcy
Organizacje korzystające z Salesforce powinny traktować połączone aplikacje i integracje jako pełnoprawne zasoby bezpieczeństwa.
Do ważnych działań należą:
- inwentaryzacja wszystkich połączonych aplikacji Salesforce
- usunięcie nieużywanych integracji
- przegląd zakresów OAuth pod kątem zasady najmniejszych uprawnień
- monitorowanie aktywności API według połączonej aplikacji
- badanie nietypowych eksportów danych
- szybkie unieważnianie i rotacja tokenów po incydentach u dostawców
- przegląd uprawnień użytkowników-gości w witrynach Experience Cloud
- ograniczenie dostępu do punktów końcowych Aura tam, gdzie to możliwe
- monitorowanie logów zdarzeń Salesforce
- szkolenie pracowników, aby nie zatwierdzali aplikacji OAuth podczas niezamówionych rozmów z rzekomym wsparciem
- wymaganie weryfikacji helpdesku za pośrednictwem znanych, bezpiecznych kanałów
Zespoły bezpieczeństwa powinny też zwracać uwagę na stare poświadczenia testowe, porzucone integracje i aplikacje dostawców, które nadal mają aktywne uprawnienia.
Zapomniane zaufanie nadal jest zaufaniem.
Atakujący mogą z niego skorzystać.
Podsumowanie
Te kampanie przeciwko Salesforce pokazują istotną zmianę w taktykach włamań do środowisk SaaS.
Atakujący nie zawsze muszą wykorzystywać podatność platformy. Mogą nadużywać zaufania, które organizacje już przyznały użytkownikom, aplikacjom, dostawcom i rolom gości.
To właśnie sprawia, że ta aktywność jest trudna do wykrycia.
Logowanie może wyglądać normalnie. Integracja może być zatwierdzona. Wywołania API mogą pochodzić z zaufanej aplikacji.
Ale prawdę o ataku zdradza zachowanie po uzyskaniu dostępu.
Dla obrońców Salesforce priorytet jest jasny: monitorować połączone aplikacje, nadzorować dostęp OAuth, ograniczać ekspozycję dostawców i użytkowników-gości oraz usuwać zapomniane poświadczenia, zanim znajdą je atakujący.
Współczesne bezpieczeństwo SaaS nie polega już wyłącznie na ochronie kont użytkowników.
Chodzi o kontrolowanie każdej zaufanej ścieżki prowadzącej do danych.
