Techniczna analiza scenariusza przebiegu ataku na polskie banki

dodał 16 lutego 2017 o 08:07 w kategorii Złośniki  z tagami: • • •
Techniczna analiza scenariusza przebiegu ataku na polskie banki

Od pojawienia się pierwszych informacji dotyczących zidentyfikowania najpoważniejszego ujawnionego ataku na polskie banki minęły już trzy tygodnie, czas zatem zebrać w jednym miejscu techniczne informacje na temat przebiegu samego ataku.

Gdy niecałe dwa tygodnie temu jako pierwsi ujawniliśmy, że kilka polskich banków padło ofiarami włamywaczy, w bankach trwały gorączkowe przeglądy infrastruktury pod kątem obecności włamywaczy i nikt nie tracił czasu na spisywanie szczegółów procesu infekcji. Od tamtego czasu pojawiło się już w sieci kilka prób opisania aspektów technicznych użytego złośliwego oprogramowania. Do tematu podeszły firmy takie jak Symantec, Booz Allen i BAE Systems – szczególnie polecamy tą ostatnią analizę, ponieważ w naszej ocenie zawiera najwięcej sprawdzonych i potwierdzonych informacji. My spróbujemy spojrzeć na sprawę kompleksowo – od wejścia na stronę KNF przez pracownika banku do pojawienia się na jego komputerze sprytnego konia trojańskiego. Nasze podsumowanie opisuje tylko jeden z obserwowanych scenariuszy ataku – wiele wskazuje na to, że inne próby mogły mieć przynajmniej częściowo inny przebieg.

Dostępna jest także anglojęzyczna wersja artykułu.

Co się działo w przeglądarce

Pierwszym krokiem do infekcji była wizyta stacji roboczej na stronie www.knf.gov.pl między 5 października 2016 a 2 lutego 2017. Witryna ta zawiera na każdej stronie skrypt

http://www.knf.gov.pl/DefaultDesign/Layouts/KNF2013/resources/accordian-src.js?ver=11

Pod koniec tego skryptu wczytywany był zewnętrzny skrypt – w zależności od miesiąca był to

http://sap.misapor.ch/vishop/view.jsp?pagenum=1

lub

http://www.eye-watch.in/design/fancybox/images.jsp?pagenum=1

Serwer kontrolowany przez przestępców weryfikował następnie, czy odwiedzający go komputer wart jest próby infekcji (między innymi prawdopodobnie w oparciu o listę klas adresowych IP leżących w kręgu zainteresowania przestępców). W razie pozytywnej decyzji o ataku serwował jeden z czterech eksploitów: atakujący wtyczkę Silverlight plik cambio.xap

4cc10ab3f4ee6769e520694a10f611d5

zawierający plik DLL lub atakujący wtyczkę Flash plik cambio.swf

6dffcfa68433f886b2e88fd984b4995a
1f2cd85583a4a56b764ba6429c2155ec

zawierający trzy exploity: CVE-2015-8651, CVE-2016-1019 oraz CVE-2016-4117. Użyte w ataku exploity były skopiowane z popularnych komercyjnych exploit kitów. W momencie ataku exploity atakowały znane już podatności – do tej pory nie natrafiono na żaden dowód użycia podatności typu 0day.

Jako parametr wywołania exploita przekazywany był shellcode, który pobierał z tego samego adresu narzędzie służące do wstępnego rozpoznania infekowanego systemu (opisane w artykule BAE). Narzędzie to odsyłało do serwera zebrane podstawowe informacje o zainfekowanej maszynie. Jeśli wynik analizy był interesujący dla operatora kontrolującego infekcję, ten mógł ręcznie oznaczyć konkretny komputer i polecić instalację na nim kolejnego elementu złośliwego oprogramowania, pobieranego jako plik perfmon.dat. Był to zaszyfrowany plik EXE, który po odszyfrowaniu był uruchamiany w atakowanym systemie.

Co się działo w komputerze

Na jednym z zainfekowanych komputerów odnaleziono plik EXE

bedceafa2109139c793cb158cec9fa48f980ff2b

który pełnił rolę instalatora kolejnej fazy infekcji. Jest to narzędzie wiersza poleceń, które przyjmuje kilka możliwych parametrów, między innymi:

-l : lista potencjalnych nazw serwisów które może wykorzystać malware
-e [NAZWA] : wypakowuje pliki DLL i CHM pod wskazaną nazwą

Instalator ze swoich zasobów odszyfrowuje i zapisuje na dysku (w odpowiednich wersjach 32 lub 64-bitowych w zależności od systemu, który infekuje), plik DLL (zabezpieczony komercyjnym pakerem Enigma utrudniającym nieco analizę pliku) oraz plik CHM. Plik DLL przybiera nazwę np. srservice.dll

e29fe3c181ac9ddbb242688b151f3310

i jest instalowany jako usługa. Plik CHM otrzymuje wtedy analogiczną nazwę srservice.chm

9216b29114fb6713ef228370cbfe4045

i jest zapisywany w folderze %WINDIR%\Help. Tak naprawdę plik CHM to zaszyfrowany plik DLL. Zainstalowana usługa odszyfrowuje go i wstrzykuje do procesu lsass.exe, przy okazji także odszyfrowując jego plik konfiguracyjny srservice.hlp

8e32fccd70cec634d13795bcb1da85ff

Pliki szyfrowane są za pomocą wariantu algorytmu RC4 zwanego Spritz.

W pliku konfiguracyjnym znajdują się między innymi adresy dwóch serwerów, wyglądające jak nazwy serwerów C&C:

tradeboard.mefound.com:443
movis-es.ignorelist.com:443

Ciekawe jest to, że wskazane domeny oraz ich adresy IP nie są faktycznymi serwerami C&C. Koń trojański co prawda rozwiązuje ich nazwy domenowe na adresy IP, ale następnie przetwarza otrzymane w odpowiedzi od serwera DNS  adresy IP za pomocą funkcji XOR ze stałym kluczem by otrzymać faktyczne adresy IP serwerów C&C.

Plik srservice.chm to docelowy element tego etapu infekcji – koń trojański, łączący się z serwerem C&C i przyjmujący od niego odpowiednie polecenia. Jest ich ponad 20, przykładowe to:

  • CMDL – wykonanie polecenia, zapisanie wyniku do pliku tymczasowego, wgranie pliku na C&C i skasowanie pliku tymczasowego
  • DEL – znalezienie i usunięcie pliku
  • DIE – wyłączenie programu
  • DIR – wyszukiwanie plików lub katalogów
  • DOWN – pobranie pliku i zapisanie pod wskazaną nazwą
  • DRIV – informacje o dyskach logicznych
  • GCFG – pobranie bieżącej konfiguracji
  • PEEX – wstrzyknięcie i uruchomienie wskazanego kodu do procesu explorer.exe
  • PKIL – zabicie procesu
  • PVEW – przegląd informacji o działających procesach
  • RUN – wykonanie programu
  • SCFG – otrzymanie nowej konfiguracji, zaszyfrowanie i zapisanie
  • UPLD – wgranie wybranego pliku na C&C
  • WIPE – znalezienie i bezpieczne usunięcie pliku

Innym zidentyfikowanym w trakcie analiz elementem złośliwego oprogramowania jest plik fdsvc.exe

9914075cc687bdc352ee136ac6579707

prawdopodobnie uruchamiany „ręcznie” przez atakujących lub pochodzący z innego procesu infekcji. Plik ten przyjmuje parametry polecenia wskazujące, do jakiego serwera ma się połączyć oraz do którego procesu ma wstrzyknąć wskazany w innym parametrze złośliwy kod. Obserwowany wstrzykiwany kod to fdsvc.dll

9cc6854bc5e217104734043c89dc4ff8

czyli zaszyfrowany plik DLL.

Podsumowanie

Nasza analiza to kompilacja informacji z wielu źródeł, co ciekawe – w dużej mierze zagranicznych, ponieważ wydobycie informacji od osób analizujących atak w Polsce było z różnych względów trudnym zadaniem. Kwestię współpracy i wymiany informacji poruszymy jutro w osobnym wpisie, tymczasem gorąco dziękujemy wszystkim analitykom, którzy chcieli i mogli podzielić się z nami efektami swojej pracy i mamy nadzieję, że ta publikacja pomoże w dalszym rozpracowywaniu działania włamywaczy.

Podobne wpisy