Subscribe to receive notifications of new posts:

Subscription confirmed. Thank you for subscribing!

Jak przeprowadzono wyrafinowany atak phishingowy – i jak go powstrzymaliśmy

Loading...

The mechanics of a sophisticated phishing scam and how we stopped it

Wczoraj, 8 sierpnia 2022 roku, firma Twilio ogłosiła, że padła ofiarą ukierunkowanego ataku phishingowego. Mniej więcej w tym samym czasie  zaatakowano w podobny sposób pracowników Cloudflare. Choć kilka osób dało się oszukać, zdołaliśmy zatrzymać atak, ponieważ stosujemy produkty Cloudflare One, a wszystkie nasze aplikacje wymagają od pracowników używania fizycznych kluczy zabezpieczeń.

Potwierdziliśmy, że nie naruszono bezpieczeństwa żadnego z systemów Cloudflare. Nasz zespół Cloudforce One odpowiedzialny za dane dot. zagrożeń przeprowadził dodatkową analizę ataku, co pozwoliło określić jego sposób działania i zebrać istotne dowody, które przyczynią się do znalezienia sprawcy.

Była to wyrafinowana operacja atakująca pracowników i systemy w taki sposób, że większość firm prawdopodobnie nie byłaby w stanie się przed nią ochronić. Ponieważ sprawca wziął na cel wiele organizacji, postanowiliśmy podzielić się naszymi spostrzeżeniami, by pomóc innym firmom rozpoznać i złagodzić ten atak.

Ukierunkowane SMS-y

20 lipca 2022 roku zespół ds. bezpieczeństwa w Cloudflare otrzymał doniesienia o wysyłanych do pracowników SMS-ach, które wyglądały na autentyczne. Zawierały one link, który zdawał się przekierowywać na stronę logowania Cloudflare w portalu Okta. Pierwsze wiadomości wysłano 20 lipca 2022 roku o godzinie 22:50 czasu UTC. W ciągu niecałej minuty co najmniej 76 pracowników otrzymało takie wiadomości na numery osobiste i służbowe. W niektórych przypadkach wiadomość wysłano nawet do członków rodzin pracowników. Nie udało nam się jeszcze ustalić, jak sprawca ataku zdobył numery telefonów pracowników. Sprawdziliśmy dzienniki dostępu do naszego katalogu pracowników i nie znaleźliśmy w nich śladów naruszenia bezpieczeństwa.

W Cloudlare działa 24 godziny na dobę zespół reagowania na incydenty bezpieczeństwa (SIRT). Wszyscy nasi pracownicy zostali nauczeni, by zgłaszać SIRT wszystko, co wydaje im się podejrzane. W ponad 90% przypadków zgłoszone do SIRT incydenty okazują się nie być zagrożeniami. To dlatego, że pracownicy są zachęcani do wysyłania zgłoszeń i nigdy nie są za nie krytykowani. W tym przypadku zgłoszenia dotyczyły jednak prawdziwego zagrożenia.

Tak wyglądały otrzymane przez pracowników wiadomości:

Zostały wysłane z czterech numerów powiązanych z kartami SIM wydanymi przez T-Mobile: (754) 268-9387, (205) 946-7573, (754) 364-6683 i (561) 524-5989. Podana w nich domena wyglądała na oficjalną: cloudflare-okta.com. Zarejestrowano ją w rejestratorze domeny Porkbun 20 lipca 2022 roku o godzinie 22:13:04 czasu UTC, a więc niecałe 40 minut przed rozpoczęciem kampanii phishingowej.

Cloudflare zbudowało nasz bezpieczny rejestrator między innymi po to, by monitorować, kiedy są rejestrowane domeny wykorzystujące markę Cloudflare, aby szybko je usuwać. Ponieważ tę domenę zarejestrowano tuż przed atakiem, nie została jeszcze opublikowana, przez co nie zdążyliśmy jej wykryć i usunąć.

Link w wiadomości prowadził do strony wyłudzającej informacje. Strona ta była hostowana przez DigitalOcean i wyglądała tak:

Dostawcą tożsamości Cloudflare jest Okta. Fałszywa strona wyglądała identycznie jak prawdziwa strona logowania Okta. Prosiła odwiedzającego o podanie nazwy użytkownika i hasła.

Phishing w czasie rzeczywistym

Udało nam się przeanalizować ładunek ataku phishingowego na podstawie wiadomości wysłanych do naszych pracowników oraz treści opublikowanej na takich portalach, jak VirusTotal, przez inne zaatakowane firmy. Gdy ofiara ataku wypełniła pola na stronie, dane logowania były natychmiast przekazywane sprawcy za pośrednictwem komunikatora internetowego Telegram. Ten ostatni punkt jest istotny, ponieważ fałszywa strona prosiła także o podanie hasła jednorazowego opartego na czasie (kod TOTP).

Przypuszczamy, że sprawca ataku otrzymywał poświadczenia w czasie rzeczywistym i wprowadzał je na prawdziwej stronie logowania firmy ofiary, co w przypadku wielu organizacji powodowało wygenerowanie kodu wysyłanego pracownikowi SMS-em lub wyświetlanego w generatorze haseł. Pracownik następnie wprowadzał kod TOTP na fałszywej stronie, która przekazywała go sprawcy ataku. Ten mógł wówczas, zanim wygasł kod TOTP, wykorzystać go do zalogowania na prawdziwej stronie logowania firmy – obchodząc w ten sposób najczęstszy sposób zabezpieczenia uwierzytelnianiem dwuskładnikowym.

Sprawna ochrona mimo potknięć

Ustaliliśmy, że troje pracowników Cloudflare dało się oszukać i wprowadziło swoje dane na fałszywej stronie. Cloudflare nie korzysta jednak z kodów TOTP. Zamiast tego każdy pracownik otrzymuje zgodny ze standardem FIDO2 klucz zabezpieczeń od takiego dostawcy, jak YubiKey. Ponieważ te fizyczne klucze są powiązane z konkretnymi pracownikami i implementują powiązanie ze źródłem, nawet wyrafinowana operacja phishingowa przeprowadzana w czasie rzeczywistym nie pozwoliłaby zebrać informacji koniecznych do zalogowania się do któregokolwiek z naszych systemów. Choć sprawca ataku próbował zalogować się do naszych systemów z wykorzystaniem skradzionych nazw użytkownika i haseł, nie mógł obejść wymagania fizycznego klucza.

Celem tej fałszywej strony nie było jednak samo wyłudzanie poświadczeń i kodów TOTP. Jeśli ktoś wprowadził wszystkie te dane, strona inicjowała pobieranie ładunku zawierającego oprogramowanie AnyDesk do zdalnego dostępu. Zainstalowanie tego oprogramowania pozwoliłoby sprawcy ataku zdalnie kontrolować komputer ofiary. Żaden z naszych pracowników nie doszedł do tego etapu. Gdyby tak jednak się stało, nasza ochrona punktów końcowych powstrzymałaby instalację oprogramowania do zdalnego dostępu.

Jak zareagowaliśmy na atak?

Oto najważniejsze z działań podjetych przez nas w odpowiedzi na ten incydent:

1. Zablokowanie fałszywej domeny za pomocą Cloudflare Gateway

Cloudflare Gateway to bezpieczna brama internetowa (SWG) zapewniająca ochronę przez zagrożeniami internetowymi oraz ochronę danych z filtrowaniem DNS/HTTP i natywnie zintegrowanym Zero Trust. Korzystamy z tego rozwiązania w naszej firmie, by zapobiegawczo identyfikować złośliwe domeny i je blokować. Nasz zespół dodał złośliwą domenę do Cloudflare Gateway, by zablokować do niej dostęp wszystkim pracownikom.

Funkcja automatycznego wykrywania złośliwych domen zidentyfikowała domenę i ją zablokowała, jednak ponieważ zarejestrowano ją krótki czas przed wysłaniem wiadomości, system nie zdążył podjąć działań, zanim kilkoro pracowników kliknęło link. Mając na względzie ten incydent, pracujemy nad przyspieszeniem procesu wykrywania i blokowania złośliwych domen. Implementujemy także kontrole dostępu do nowo zarejestrowanych domen – jest to opcja, którą oferujemy klientom, a z której sami dotychczas nie korzystaliśmy.

2. Zidentyfikowanie wszystkich dotkniętych problemem pracowników i zresetowanie wykradzionych poświadczeń

Porównaliśmy odbiorców SMS-ów z aktywnością logowania i wykryliśmy próby uwierzytelnienia kont pracowników w ramach ataku. Wykryliśmy próby logowania zablokowane dzięki wymaganiu fizycznego klucza (U2F), co oznacza, że użyto prawidłowego hasła, ale nie udało się zweryfikować drugiego składnika. Zresetowaliśmy dane logowania oraz wszystkie aktywne sesje trojga pracowników, których dane logowania zostały skradzione. Przeskanowaliśmy również ich urządzenia.

3. Identyfikacja i usunięcie infrastruktury źródła zagrożenia

Domena wykorzystana w ataku była nowa, zarejestrowana przez Porkbun i hostowana przez DigitalOcean. Założono ją niecałą godzinę przez pierwszą falą ataku. Strona miała front-end Nuxt.js i back-end Django. W wyniku naszego zgłoszenia DigitalOcean zamknęło serwer źródła zagrożenia. Podobnie Porkbun przejęło kontrolę nad złośliwą domeną.

Na podstawie nieudanych prób logowania ustaliliśmy, że sprawca ataku korzystał z oprogramowania VPN Mullvad i używał przeglądarki Google Chrome oraz systemu Windows 10. Adresy IP VPN sprawcy ataku to 198.54.132.88 oraz 198.54.135.222. Są one przypisane Tzulo, dostawcy serwerów z siedzibą w USA, który podaje na swojej stronie internetowej, że ma serwery w Los Angeles i Chicago. W rzeczywistości wygląda jednak na to, że pierwszy adres był powiązany z serwerem w okolicach Toronto, a drugi z serwerem w okolicach Waszyngtonu (DC). Zablokowaliśmy tym adresom IP dostęp do naszych usług.

4. Aktualizacja wykrywania zagrożeń w celu identyfikacji kolejnych prób ataku

Na podstawie zebranych informacji o tym ataku włączyliśmy do naszego istniejącego systemu wykrywania dodatkowe sygnały ostrzegawcze, odnoszące się do tego sprawcy. Do czasu publikacji tego artykułu nie zaobserwowaliśmy kolejnych fal ataku na naszą firmę. Dane z serwera wskazują jednak, że sprawca zaatakował również inne organizacje, w tym Twilio. Skontaktowaliśmy się z tymi organizacjami i przekazaliśmy im zebrane przez nas informacje.

5. Inspekcja dzienników dostępu do usługi pod kątem innych oznak ataku

Po ataku sprawdziliśmy wszystkie dzienniki systemu pod kątem dodatkowych śladów cyfrowych sprawcy. Ponieważ Cloudflare Access stanowi punkt kontroli wszystkich aplikacji Cloudflare, możemy przeszukać dzienniki i wykryć wszelkie ślady naruszenia bezpieczeństwa systemów. Ponieważ w ataku wykorzystano telefony pracowników, starannie przeanalizowaliśmy także dzienniki dostawców usług dla pracowników. Nie znaleźliśmy dowodów naruszenia bezpieczeństwa.

Wyciągnięte wnioski i plan dodatkowych działań

Każdy atak jest dla nas nauką. Choć ten był nieudany, wprowadzamy dodatkowe zmiany na podstawie zebranych przez nas informacji. Modyfikujemy ustawienia Cloudflare Gateway, by ograniczyć lub odizolować dostęp do stron internetowych na domenach zarejestrowanych w ciągu ostatniej doby. Wszelkie strony, które nie są na liście dozwolonych, a zawierają terminy takie jak „cloudflare”, „okta”, „sso” i „2fa”, będą obsługiwane w odizolowanej przeglądarce. Zwiększamy także wykorzystanie technologii Cloudflare Area 1 rozpoznającej ataki phishingowe do skanowania sieci Web w poszukiwaniu stron, które mają służyć do zaatakowania Cloudflare. Na koniec wzmacniamy implementację Access, by zapobiegać logowaniom z nieznanych sieci VPN, lokalnych serwerów proxy i dostawców infrastruktury. Są to standardowe funkcje produktów, które oferujemy naszym klientom.

Atak pokazał także istotność trzech rzeczy, które robimy dobrze. Po pierwsze, dostęp do każdej aplikacji wymaga fizycznego klucza. Podobnie jak Google, od czasu wprowadzenia tej metody uwierzytelniania nie mieliśmy do czynienia z ani jednym udanym atakiem phishingowym. Narzędzia takie jak Cloudflare Access ułatwiają wsparcie fizycznych kluczy nawet w starszych aplikacjach. Jeśli Twoja organizacja jest zainteresowana, jak wdrożyliśmy te klucze, skontaktuj się z nami pod adresem [email protected], a nasz zespół ds. bezpieczeństwa chętnie podzieli się dobrymi praktykami, których nauczyliśmy się w tym procesie.

Po drugie, używamy własnej technologii Cloudflare do ochrony naszych pracowników i systemów. Rozwiązania Cloudflare One, takie jak Access i Gateway, były kluczowe w ochronie przed tym atakiem. Skonfigurowaliśmy implementację Access tak, by każda aplikacja wymagała fizycznego klucza. Access tworzy także jedno miejsce logowania do uwierzytelniania wszystkich aplikacji. W razie konieczności umożliwia także zakończenie sesji użytkownika z potencjalnie naruszonymi zabezpieczeniami. Gateway pozwala nam szybko zablokować złośliwe strony i ustalić, którzy pracownicy mogli zostać oszukani. Wszystkie te funkcje są dostępne dla klientów Cloudflare w ramach pakietu Cloudflare One, a ten atak dowodzi ich skuteczności.

Po trzecie, kultura podejrzliwości bez obwiniania pracowników ma zasadnicze znaczenie dla bezpieczeństwa. Trzy osoby, które dały się oszukać w ataku, nie otrzymały nagany. Wszyscy jesteśmy ludźmi i popełniamy czasem błędy. To niezmiernie ważne, żeby je zgłaszać, a nie tuszować. Ten incydent jest kolejnym przykładem tego, że bezpieczeństwo jest częścią pracy każdego członka zespołu Cloudflare.

Szczegółowa oś czasu wydarzeń

2022-07-20 22:49 UTC Sprawca wysyła ponad 100 SMS-ów do pracowników Cloudflare i ich rodzin.
2022-07-20 22:50 UTC Pracownicy zaczynają zgłaszać SMS-y zespołowi ds. bezpieczeństwa.
2022-07-20 22:52 UTC Blokujemy w Cloudflare Gateway domenę źródła zagrożenia na urządzeniach służbowych.
2022-07-20 22:58 UTC Wszyscy pracownicy otrzymują ostrzeżenia przez chat i pocztę e-mail.
2022-07-20 22:50 UTC to
2022-07-20 23:26 UTC
Monitorowanie telemetrii w dzienniku systemu Okta i dziennikach HTTP Cloudflare Gateway w celu zidentyfikowania naruszenia bezpieczeństwa poświadczeń. Wyczyszczenie sesji logowania i zawieszenie dotkniętych kont.
2022-07-20 23:26 UTC Dostawca hostingu zamyka stronę wyłudzającą dane.
2022-07-20 23:37 UTC Reset skradzionych poświadczeń.
2022-07-21 00:15 UTC Analiza infrastruktury i możliwości sprawcy.

Wskaźniki naruszenia bezpieczeństwa

Wartość Typ Kontekst i mapowanie MITRE
cloudflare-okta[.]com hosted on 147[.]182[.]132[.]52 Adres URL strony T1566.002: phishing: link spear phishing wysłany do użytkowników
64547b7a4a9de8af79ff0eefadde2aed10c17f9d8f9a2465c0110c848d85317a SHA-256 T1219: oprogramowanie do dostępu zdalnego rozpowszechniane przez sprawcę

Co możesz zrobić

Jeśli w Twoim środowisku zdarzają się podobne ataki, zachęcamy do kontaktu pod adresem [email protected] Chętnie podzielimy się dobrymi praktykami w zakresie bezpieczeństwa Twojej firmy. A może chcesz pracować z nami nad wykrywaniem i łagodzeniem kolejnych ataków? Prowadzimy rekrutację do zespołu wykrywania i reagowania. Dołącz do nas!

Chronimy całe sieci korporacyjne, pomagamy klientom sprawnie budować aplikacje w skali internetowej, przyspieszamy wszelkie strony i aplikacje internetowe , zapobiegamy atakom DDoS, powstrzymujemy hakerów, i możemy Ci pomóc na drodze do modelu Zero Trust

Odwiedź 1.1.1.1, z dowolnego urządzenia, by pobrać naszą darmową aplikację, dzięki której Twój Internet będzie szybszy i bezpieczniejszy.

Aby dowiedzieć się więcej o naszej misji zbudowania lepszego Internetu, zacznij tutaj Jeśli interesuje Cię zmiana ścieżki kariery, sprawdź nasze otwarte stanowiska

Bezpieczeństwo Analiza przypadku Phishing (PL) Cloudflare Gateway (PL) Cloudflare Access (PL)

Follow on Twitter

Matthew Prince |@eastdakota
Daniel Stinson-Diess |@shellcromancer
Cloudflare |Cloudflare

Related Posts