GitHub jako narzędzie ataku: północnokoreańska grupa APT używa fałszywych ofert do rozsyłania malware

Propozycja zlecenia

Dział sprzedaży pewnej firmy dostał zapytanie o dostępność product designera do pracy nad systemem do obsługi zakładów bukmacherskich. Potencjalny klient podesłał link do repozytorium na GitHubie jako przykład interesującego go docelowego zakresu funkcjonalności aplikacji. Ofertę przekazano do odpowiedniego pracownika, który miał za zadanie ją zweryfikować. Jego podejrzenie wzbudziła nazwa otrzymanego repozytorium. Nie pasowała ona do typu produktu, dla którego wspomniane repo miało być wzorem. Po przejrzeniu zawartości zauważył, że otrzymana aplikacja to gra, co potwierdziło jego wątpliwości. Zdecydował się podzielić tym przypadkiem z naszymi analitykami oraz przekazał im potrzebne informacje

Poniżej otrzymana wiadomość:

Inne ofiary

Po otrzymaniu zgłoszenia przystąpiliśmy do krótkiej analizy podobnych incydentów. Udało nam się znaleźć wzmianki o próbie identycznego ataku w mediach społecznościowych. Dotarliśmy do wpisów, które opisywały podobne sytuacje i ostrzegały innych użytkowników. Według nich, ofiarą padła jedna osoba  Zauważyliśmy, że użytkownicy otrzymywali wiadomości od przestępców już od miesiąca, a sama kampania była wycelowana również w osoby prywatne, bez ukierunkowania na konkretny region.

Zawartość złośliwego repozytorium

Przystąpiliśmy do analizy złośliwego repozytorium, które zawierało projekt w technologii JavaScript, korzystający z managera paczek NPM. Użyte zależności nie wzbudzały podejrzeń, a plik package-lock.json nie wskazywał na ingerencję w użyte paczki.

Paczki z pliku package.json:

Po sprawdzeniu tego elementu zajęliśmy się analizą kodu. Repozytorium zawierało de facto dwa projekty – wyżej wspomnianą grę oraz drugi projekt o nazwie backend. Sam kod umieszczonej tam gry był skradziony z innego publicznego repozytorium dostępnego na GitHubie. Naszą uwagę przykuł drugi projekt, a w szczególności plik o nazwie error.js, który został zaciemniony.

Poniżej zawartość pliku error.js:

Dokonaliśmy deobfuskacji oraz analizy zawartości. Głównymi zadaniami pliku były:

• komunikacja z serwerem C2,
• pobranie interpretera języka Python na host ofiary oraz rozpakowanie go,
• kradzież danych z przeglądarki (w tym portfele kryptowalut),
• pobranie oraz instalacja malware.

Analiza działania złośliwego oprogramowania

Postanowiliśmy zająć się analizą działania samego złośliwego oprogramowania. W tym celu przygotowaliśmy wyizolowane środowisko wirtualne bazujące na systemie Windows z nakładką FlareVM.

Uruchomiliśmy złośliwe oprogramowanie i obserwowaliśmy jego zachowanie, przechwytując w międzyczasie ruch sieciowy oraz listę rozpoczętych procesów.

Loader malware

Po uruchomieniu, oprogramowanie zaczęło pobierać interpreter dla języka Python, a następnie malware znany pod nazwą InvisibleFerret. 

Poniżej lista procesów (moment pobierania dodatkowych komponentów i eksfiltracji danych):

Udało nam się również zebrać listę hostów użytych podczas ładowania danych. Przedstawiamy je w tabeli poniżej:

Endpoint	Opis
http://1.2.3.4/pdown	Pobiera interpreter języka Python z bibliotekami
http://1.2.3.4/client/:id_kampanii/:grupa	Pobiera malware
http://1.2.3.4/keys	Wysyła dane, zdobyte przez loader
http://1.2.3.4/uploads	Wysyła pozostałe dane, m.in portfele kryptowalut

Malware InvisibleFerret

InvisibleFerret to malware, który został już opisany przez firmę Palo Alto Network w artykule z listopada 2023 roku. Mimo że od wspomnianego artykułu minął rok, to malware nadal jest w użyciu. Analiza oprogramowania, które zostało wykorzystane do opisywanego ataku, wykazała następujące funkcjonalności:

• identyfikacja zarażonego hosta (adres IP + geolokalizacja, informacje nt. hosta),
• zdalna kontrola (wykonywanie komend otrzymanych od serwera C2 oraz możliwość zainstalowania oprogramowania AnyDesk),
• keylogger z funkcją eksfiltracji danych ze schowka systemowego,
• kradzież danych (w tym z przeglądarek).

Po pobraniu i uruchomieniu pliku podstawowego, tj. main_:id_kampanii_:grupa.py, oprogramowanie pobiera dodatkowe skrypty, tj.:

• pay, które odpowiada za identyfikację hosta, kradzież danych oraz kontrolę hosta,
• bow, które odpowiada za kradzież danych z przeglądarek,
• adc, które odpowiada za instalację oprogramowania AnyDesk,
• mlip, które odpowiada za logowanie klawiszy (keylogger) oraz kradzież danych z schowka.

Poniżej fragmenty kodu wyżej omawianych skryptów:

Pay (uruchamia reverse shella)

Bow (kradnie dane z przeglądarki na platformie Windows)

Adc (ustawia konfigurację pozwalającą atakującym na podłączenie się do ofiary poprzez aplikację AnyDesk)

Mlip (loguje klawisze i kradnie danych ze schowka)

Dodatkowo przeanalizowaliśmy mechanizm C2 pozwalający na kontrolę nad urządzeniem ofiary. Złośliwe oprogramowanie używa do tego celu serwisu nasłuchującego na innym niż API służące do komunikacji (tj. wysyłanie danych i pobieranie plików) porcie. System ten ma funkcjonalność heartbeat, czyli wysyłanie statusu hosta. Co jakiś czas komunikuje się z serwerem C2 i czeka na dalsze instrukcje. W oprogramowaniu znajdziemy 8 komend przedstawionych w poniższej tabeli.

Komenda	Opis
ssh_cmd	Zamyka sesję i terminuje proces python.exe.
ssh_obj	Wykonuje żądaną komendę.
ssh_clip	Wysyła dane zgromadzone przez keyloggera.
ssh_run	Uruchamia komponent bow odpowiedzialny za kradzież danych z przeglądarki.
ssh_upload	Wysyła pliki wykradzione z hosta ofiary.
ssh_env	Szuka i wysyła pliki .env.
ssh_kill	Terminuje procesy przeglądarki Brave oraz Chrome.
ssh_any	Pobiera komponent adc i uruchamia go.

Dzięki artykułowi firmy Palo Alto Networks zauważyliśmy, że wprowadzono pewne ulepszenia do malware. Wersja sprzed roku wysyłała pliki do serwera FTP podanego w requeście. Atakujący przesyłali w swoim żądaniu dane uwierzytelniające do serwera FTP (tj. adres, login oraz hasło), co w teorii pozwoliłoby analitykom z Palo Alto Networks na dostęp do skradzionych danych (jeżeli konfiguracja serwera FTP pozwoliłaby również na odczyt plików, a nie tylko zapis). Obecna wersja natomiast nie przesyła bezpośrednio danych uwierzytelniających – operację zastąpiono komunikacją z serwerem HTTP.

Analiza serwera C2

Po analizie kodów źródłowych złośliwej aplikacji postanowiliśmy przyjrzeć się bliżej serwerowi C2. Korzystając z publicznie dostępnych narzędzi, które bez naszej ingerencji skanują internet w poszukiwaniu ciekawych informacji (np. otwartych portów, usług, wersji), tj. shodan, censys, uzyskaliśmy listę aktywnych usług. Wiele z nich wskazywało na serwery HTTP (xampp), a także serwery NodeJS (Express.js). Według historii dostępnej na platformie censys.io, mogliśmy stwierdzić, że host, na którym umieszczony był serwer C2, najprawdopodobniej nie został przejęty podczas innego ataku, a został zakupiony. Jako że usługi były publicznie dostępne, a porty zostały już zaindeksowane, postanowiliśmy sprawdzić, co oferują wykryte zasoby. Na jednym z portów zidentyfikowanych jako usługa NodeJS hostowana była strona panelu zarządzania. W wyniku dalszego rekonesansu i błędów konfiguracji udało się nam dotrzeć do niezabezpieczonego kodu źródłowego strony. Analiza powyższego ujawniła listę dostępnych endpointów oraz szereg krytycznych błędów bezpieczeństwa (m.in o CVSS 3.0 wynoszącym nawet 9.4). Odpytując jeden z endpointów, który nie wymagał uwierzytelnienia, aplikacja przestała na chwilę odpowiadać. Ostatecznie okazało się, że powodem było utworzenie ważącego kilkadziesiąt megabajtów pliku z danymi wrażliwymi zaatakowanych osób i przejętych maszyn. Uzyskany plik wraz z naszą analizą został bezzwłocznie przekazany organom takim jak CERT Polska, a lokalną kopię u badaczy natychmiast permanentnie usunięto.

Kto za tym stał?

Nasze prywatne śledztwo zakończyło się na serwerze zlokalizowanym w Niemczech. Jednakże analiza malware oraz sposobu działania atakujących dosyć jasno wskazują na powiązania z grupą opisaną wcześniej przez Palo Alto (https://unit42.paloaltonetworks.com/two-campaigns-by-north-korea-bad-actors-target-job-hunters/) oraz CN-Sec (https://cn-sec.com/archives/3271109.html) – The Lazarus Group (APT38).

Wnioski końcowe

Otrzymując podobną korespondencję albo pobierając nieznane nam repozytoria powinniśmy postępować według następujących wytycznych:

• sprawdzamy reputację danego repozytorium,
• analizujemy kod przed jego uruchomieniem,
• uruchamiamy kod w wyizolowanym jednorazowym środowisku wirtualnym,
• w przypadku wykrycia nieprawidłowości w pobranym skrypcie należy to zgłosić do:
  • lokalnego CERT-u (np. CERT Polska).
  • dostawcy usługi repozytoriów (np. GitHub).
• w przypadku infekcji należy zrobić to, co powyżej, a ponadto:
  • odłączyć urządzenie od sieci,
  • zrobić zrzut pamięci urządzenia do dalszej analizy powłamaniowej,
  • zgłosić zdarzenie organom ścigania.

Autorzy: Kamil Szczurowski & Robert “ProXy” Kruczek