McKesson: wyciek danych. ShinyHunters wskazuje na vishing i Okta SSO

Szczegółowy łańcuch ataku pochodzi jednak z innego źródła. Grupa ShinyHunters twierdzi, że przeprowadziła vishing przeciw kilku pracownikom McKesson, przejęła konta Okta SSO, a następnie uzyskała dostęp do Salesforce i Snowflake. Grupa mówi również o około 1 TB danych i 284 mln rekordów. BleepingComputer zaznacza, że tych szczegółów nie zweryfikował niezależnie, a McKesson nie potwierdził publicznie ani aktora, ani dokładnej drogi wejścia, ani skali danych podawanej przez napastników.

Dla firm ten przypadek jest interesujący nie dlatego, że pojawiła się nowa luka w oprogramowaniu. Publiczne informacje wskazują na problem w warstwie tożsamości i decyzji użytkownika. Jeżeli telefon od osoby podszywającej się pod IT prowadzi do przejęcia SSO, konsekwencje mogą objąć wiele połączonych usług. Dlatego vishing w firmie trzeba ćwiczyć razem z procedurami helpdesku, MFA i reagowaniem na podejrzane logowanie.

Co McKesson rzeczywiście potwierdził

W tym incydencie łatwo pomieszać informacje pochodzące od spółki z twierdzeniami grupy prowadzącej wymuszenie. Rozdzielenie tych dwóch warstw jest podstawą rzetelnego opisu.

McKesson w raporcie dla SEC potwierdził, że 25 sierpnia wykrył incydent dotyczący swoich systemów informacyjnych. Dochodzenie było wtedy na wczesnym etapie. Na dzień złożenia raportu, 28 sierpnia, spółka nie stwierdziła, aby zdarzenie miało lub mogło mieć istotny wpływ na jej sytuację finansową albo wyniki działalności.

W osobnym komunikacie dla klientów, cytowanym przez BleepingComputer i Malwarebytes, McKesson potwierdził nieautoryzowany dostęp do części aplikacji podmiotów trzecich i eksfiltrację części danych. Według aktualizacji zakres ten był związany z częścią klientów jednostek Oncology & Multispecialty oraz Medical-Surgical.

To jest część potwierdzona przez organizację.

McKesson nie podał natomiast publicznie, że pierwszym krokiem był vishing. Nie potwierdził, że przejęto Okta SSO, że atakujący weszli do Salesforce albo Snowflake ani że wykradziono dokładnie 1 TB danych. Nie podał także, że w zbiorze znajdowało się 284 mln rekordów.

Co twierdzi ShinyHunters

Grupa ShinyHunters powiedziała BleepingComputer, że zaatakowała przez telefon wielu pracowników McKesson. Według grupy rozmowy doprowadziły do przejęcia kilku kont Okta używanych do jednokrotnego logowania. Te konta miały następnie dać dostęp do środowisk Salesforce i Snowflake.

BleepingComputer podał dodatkowo, że z innego źródła dowiedział się o domenie mckesson[.]claims, która miała być użyta podczas kampanii. Taki wzorzec pasuje do aktywności obserwowanej wcześniej przy atakach na inne firmy: domena zawiera nazwę organizacji i udaje element firmowego helpdesku albo procesu SSO.

Według ShinyHunters eksfiltracja trwała od 21 do 25 sierpnia i objęła około 1 TB danych. Grupa twierdzi również, że w Snowflake znajdowało się około 284 mln rekordów związanych z danymi pacjentów. Podała też rozbudowaną listę kategorii danych, które miały trafić w jej ręce.

Te twierdzenia trzeba traktować jako informacje od strony, która prowadzi wymuszenie i ma interes w przedstawieniu incydentu jako jak największego. BleepingComputer wprost napisał, że nie zweryfikował tych szczegółów niezależnie. McKesson również ich publicznie nie potwierdził.

284 mln rekordów to nie 284 mln pacjentów

Ta liczba jest szczególnie podatna na błędne powielanie.

Pierwsze relacje mówiły o danych 284 mln pacjentów. Grupa ShinyHunters doprecyzowała później BleepingComputer, że chodzi o około 284 mln rekordów lub wierszy danych, a nie o 284 mln unikalnych osób. Grupa przyznała też, że nie przeanalizowała całego zbioru i nie zna liczby osób reprezentowanych w tych rekordach.

Jedna osoba może mieć wiele wpisów dotyczących wizyt, recept, przesyłek, rozliczeń lub innych zdarzeń. Z samej liczby wierszy nie można więc wyprowadzić liczby poszkodowanych osób.

Dopóki McKesson nie poda pełniejszego zakresu albo nie pojawią się wiarygodne informacje regulacyjne, prawidłowe sformułowanie brzmi: grupa ShinyHunters twierdzi, że zdobyła około 284 mln rekordów; nie wiadomo, ilu unikalnych osób one dotyczą.

Jak telefon może otworzyć drogę do SSO i SaaS

Niezależnie od tego, które szczegóły przypadku McKesson zostaną ostatecznie potwierdzone, sam model ataku jest dobrze udokumentowany przez zespoły zajmujące się bezpieczeństwem tożsamości.

Okta Threat Intelligence opisał zestawy phishingowe projektowane specjalnie do pracy z vishingiem. Napastnik prowadzi rozmowę w czasie rzeczywistym, kieruje użytkownika na fałszywą stronę i równocześnie próbuje zalogować się do prawdziwej usługi. Gdy pojawia się kolejne żądanie MFA, może natychmiast dostosować instrukcje i przekonać rozmówcę do wykonania potrzebnej czynności.

To mechanizm bardziej przekonujący niż statyczny e-mail. Użytkownik może słyszeć osobę, która zna nazwę firmy, nazwiska pracowników i wygląd firmowego procesu logowania. Jeżeli rozmówca wywoła prawdziwe powiadomienie MFA w odpowiednim momencie, może przedstawić je jako część rzekomej procedury wsparcia.

Po przejęciu konta SSO ryzyko nie kończy się na jednym serwisie. SSO celowo upraszcza dostęp do wielu aplikacji. To poprawia zarządzanie tożsamościami, ale oznacza też, że przejęte konto może stać się punktem wejścia do kilku połączonych usług, jeżeli dodatkowe warunki dostępu nie zatrzymają sesji.

Właśnie tę szerszą klasę ataków opisujemy w artykule Okta pod ostrzałem. Przypadek McKesson jest wart osobnego omówienia, ponieważ spółka potwierdziła już eksfiltrację danych z aplikacji podmiotów trzecich, nawet jeśli dokładna droga przez Okta, Salesforce i Snowflake pozostaje na razie twierdzeniem napastników.

Gdzie można przerwać taki łańcuch

Health-ISAC opisuje powtarzalny model ataków na sektor ochrony zdrowia: vishing, manipulacja procesem resetu lub rejestracji MFA, przejęcie SSO, przejście do połączonych aplikacji SaaS i szybka eksfiltracja danych. Obrona nie powinna zależeć od jednego punktu.

1. Zweryfikuj osobę dzwoniącą innym kanałem

Pracownik i helpdesk nie powinni opierać decyzji tylko na tym, co mówi rozmówca przychodzący. Jeżeli ktoś prosi o zmianę hasła, reset MFA, rejestrację urządzenia albo wejście na stronę logowania, bezpiecznym wzorcem jest przerwanie rozmowy i oddzwonienie na numer zapisany w firmowym katalogu.

Health-ISAC rekomenduje także model, w którym reset nie jest kończony w tej samej rozmowie przychodzącej. Dla kont uprzywilejowanych można wymagać dodatkowego potwierdzenia przez przełożonego albo drugi zaufany kanał.

2. Używaj metod MFA odpornych na phishing

Powiadomienie push lub kod jednorazowy może zostać wykorzystany w rozmowie prowadzonej na żywo. Okta zwraca uwagę, że nawet number matching nie jest z definicji odporny na phishing, ponieważ napastnik może powiedzieć użytkownikowi, jaki numer ma wybrać lub wpisać.

Metody oparte na FIDO/WebAuthn lub passkeys wiążą uwierzytelnienie z prawidłową usługą i ograniczają możliwość przeniesienia procesu na fałszywą stronę. Nie rozwiązują wszystkich problemów związanych z odzyskiwaniem konta i helpdeskiem, ale usuwają część scenariuszy opartych na przekazywaniu kodu lub akceptacji push.

3. Nie pozwalaj, aby poprawne SSO automatycznie otwierało wszystko

Dostęp do szczególnie wrażliwych aplikacji może zależeć także od stanu urządzenia, ryzyka sesji, lokalizacji albo dodatkowego uwierzytelnienia. W opisanym wcześniej przypadku ReliaQuest napastnik zdobył prawidłową sesję po wyłudzeniu hasła i akceptacji MFA, ale device trust zablokował przejście do aplikacji.

To pokazuje znaczenie kilku niezależnych warstw. Awareness ma zmniejszać prawdopodobieństwo błędu. Kontrole tożsamości i urządzenia mają ograniczać skutki, jeżeli błąd mimo wszystko nastąpi.

4. Monitoruj zmiany tożsamości i pobieranie danych z SaaS

Po podejrzanym telefonie zespół bezpieczeństwa powinien patrzeć szerzej niż na zmianę hasła. Istotne są nowe metody MFA, rejestracje urządzeń, nietypowe sesje, zgody OAuth, zmiany konfiguracji konta i aktywność w aplikacjach dostępnych przez SSO.

Health-ISAC zaleca również alarmowanie na nietypowe masowe pobieranie danych i anomalie API w usługach SaaS. Jeżeli model biznesowy napastnika opiera się na szybkim zabraniu danych, wykrywanie nietypowej aktywności po udanym logowaniu jest równie ważne jak samo wykrycie logowania.

Co ćwiczyć z pracownikami i helpdeskiem

Klasyczny test phishingowy sprawdza zwykle e-mail: czy użytkownik kliknie, poda dane albo zgłosi wiadomość. Vishing wymaga innego zestawu zachowań.

W realistycznym ćwiczeniu pracownik powinien umieć:

• przerwać rozmowę, gdy osoba podająca się za IT prosi o hasło, kod, akceptację MFA lub wejście na nietypową stronę;
• samodzielnie odnaleźć znany numer helpdesku i oddzwonić;
• nie ufać numerowi wyświetlonemu na telefonie jako dowodowi tożsamości rozmówcy;
• zgłosić próbę socjotechniki nawet wtedy, gdy nie podał żadnych danych;
• powiedzieć zespołowi bezpieczeństwa, czy w trakcie rozmowy pojawiło się prawdziwe powiadomienie MFA, logowanie albo reset konta.

Helpdesk powinien ćwiczyć osobny wariant: rozmówca twierdzi, że zgubił telefon, nie może zalogować się do MFA, pracuje z nowego urządzenia albo potrzebuje pilnego resetu przed spotkaniem. Celem nie jest rozpoznanie głosu oszusta, lecz konsekwentne przejście przez niezależną procedurę weryfikacji.

Co zrobić po podejrzanym telefonie lub logowaniu

Jeżeli użytkownik podał dane, zatwierdził MFA albo wykonał instrukcje rozmówcy, reakcja nie powinna kończyć się na zmianie hasła.

Zespół IT lub SOC powinien rozważyć co najmniej:

1. unieważnienie podejrzanych sesji i tokenów;
2. zmianę hasła oraz sprawdzenie metod MFA i zarejestrowanych urządzeń;
3. analizę logów dostawcy tożsamości z czasu rozmowy;
4. sprawdzenie aplikacji dostępnych przez SSO pod kątem nietypowych logowań i pobierania danych;
5. weryfikację nowych zgód OAuth, reguł, delegacji i zmian konfiguracji konta;
6. zabezpieczenie logów i osi czasu zdarzeń, zanim część danych zostanie nadpisana;
7. ocenę, czy podobne telefony otrzymali inni pracownicy.

Szybkie zgłoszenie przez użytkownika ma tutaj dużą wartość. Informacja „ktoś właśnie dzwonił i kazał mi zatwierdzić logowanie” pozwala korelować rozmowę z konkretnymi zdarzeniami w logach, zamiast odkrywać je dopiero po zauważeniu nietypowej aktywności w aplikacji.

Co McKesson wnosi ponad wcześniejsze przypadki

PHISHLY ma już szeroki poradnik o vishingu oraz osobne materiały o atakach na Okta i SSO. Opisaliśmy też ReliaQuest, gdzie socjotechnika doprowadziła do aktywnej sesji, ale dodatkowe warunki dostępu zablokowały wejście do aplikacji.

McKesson pokazuje inną stronę tego samego problemu. Spółka potwierdziła, że doszło do nieautoryzowanego dostępu do części aplikacji podmiotów trzecich i eksfiltracji danych. Jednocześnie szczegółowy opis drogi przez vishing i Okta do Salesforce oraz Snowflake pozostaje twierdzeniem ShinyHunters.

To rozróżnienie jest użyteczne szkoleniowo. Organizacja nie powinna czekać na pełną publiczną atrybucję konkretnego incydentu, aby ćwiczyć zachowania przeciw dobrze udokumentowanemu modelowi vishingu i przejęcia tożsamości. Nie powinna też budować programu bezpieczeństwa na niezweryfikowanych szczegółach z serwisu grupy wymuszającej okup.

Jak przełożyć ten przypadek na test phishingowy

W testach phishingowych dla firm można bezpiecznie odtworzyć momenty decyzyjne z takiego łańcucha bez dotykania prawdziwych kont i danych.

Scenariusz może zaczynać się od telefonu lub kontrolowanej wiadomości zapowiadającej kontakt z IT. Użytkownik trafia na stronę szkoleniową imitującą proces wsparcia, ale system nie zbiera prawdziwego hasła ani nie przekazuje żadnej akceptacji MFA do zewnętrznej usługi. Mierzyć można próbę wykonania instrukcji, przerwanie kontaktu, zgłoszenie i czas reakcji.

Osobne ćwiczenie dla helpdesku może sprawdzać, czy pracownik wsparcia uruchomi reset po rozmowie przychodzącej, czy wymusi zweryfikowane oddzwonienie i dodatkową kontrolę tożsamości. To bliżej rzeczywistych warunków ataku niż kolejna kampania oparta wyłącznie na podejrzanym linku w e-mailu.

Podsumowanie

McKesson potwierdził realny incydent i eksfiltrację danych z części aplikacji podmiotów trzecich. Nie potwierdził jednak publicznie szczegółowego scenariusza, który grupa ShinyHunters opisuje jako vishing prowadzący przez Okta SSO do Salesforce i Snowflake.

Dla zespołów bezpieczeństwa nie zmienia to praktycznego problemu. Vishing zsynchronizowany z fałszywym logowaniem i prawdziwymi żądaniami MFA jest dobrze udokumentowaną techniką. Jeżeli jedno konto SSO otwiera wiele aplikacji, organizacja potrzebuje równocześnie szkolenia użytkowników, twardych procedur helpdesku, metod MFA odpornych na phishing, dodatkowych warunków dostępu oraz monitorowania aktywności po zalogowaniu.

Telefon może być pierwszym krokiem technicznego incydentu. Dlatego reakcję na telefon od „IT” trzeba projektować tak samo konkretnie jak reakcję na podejrzany e-mail.