16.02.2017 | 08:07

Adam Haertle

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.

Powrót

Komentarze

  • 2017.02.16 08:40 PM

    Z tego co wiem do dzisiaj nie ma stanowiska KNF w tej sprawie…

    Odpowiedz
    • 2017.02.16 08:45 Adam

      Jest, zaczyna się od „stwierdzono próbę ataku”…

      Odpowiedz
  • 2017.02.16 08:47 adf88

    „W momencie ataku exploity atakowały znane już podatności” Czyli stacje robocze nie są aktualizowane na bieżąco i hulają na przestarzałym sofcie? Hmmm….

    Odpowiedz
    • 2017.02.16 16:28 Najstarszy syn ks. proboszcza

      Malo tego, ktos ma w d*pie czy userzy instaluja sobie takie gowna jak Flash czy Silverlight.

      Odpowiedz
  • 2017.02.16 09:45 Przemek

    Jeśli szukasz informacji o TTP/Narzędziach/Artefaktach sieciowych lub na hostach w kontekście tych ataków to zapraszamy do współpracy – http://blog.whitecatsec.com/2017/02/knf-studium-przypadku-pytania.html.

    Obracamy opisaną m.in. przez z3s perspektywę atakującego na perspektywę broniącego/poszukującego.

    Odpowiedz
  • 2017.02.16 09:51 Piotr

    Pytanie nr pierwsze i ostanie: CO TO ZA DZIAŁ BEZPIECZEŃSTWA W BANKU, KTÓRY POZWALA NA INSTALACJĘ FLASHA/SILVERLIGHTA/JAVY NA STACJI ROBOCZEJ podłączonej do publicznej sieci? Kompromitacja na starcie.

    Odpowiedz
    • 2017.02.16 13:11 JA?!

      Niestety ale owe technologie nadal są używane w oprogramowaniu, choćby java do obsługi czytnika kart służącego logowania przy użyciu karty (https://www.getinbank.pl/strona/narzedzia-do-pobrania-dla-klientow-GB24), jak i oprogramowanie które zostało napisane i nikt już technologii nie zmieniał na nową…

      Odpowiedz
    • 2017.02.16 14:14 Adam

      Flash/Java/Silverligh sa ok, ale warunek podstawowy, musza byc na updatowane. Patrzac na czas w ktorym dokonano wlamania, flash nie byl aktualizowany przez okres 4-5 miesiecy. Pomijam fakt, ze pewnie uzytkownik na stacji zapewnie byl grupie administratorow lokalnych. Za duzo zmian tam zostalo wykonanych, na ktore nawet dziurawy flash by sobie pozwolil. Smialo mozna powiedziec, ze dzial odpowiedzialny za aplikacje i security team nie wykazali sie :)

      Odpowiedz
  • 2017.02.16 15:09 gosc

    Szydło na wniosek przewodniczącego Komisja Nadzoru Finansowego odwołała dwóch wiceszefów KNF: Lesława Gajka i Wojciecha Kwaśniaka. Czyzby to bylo poklosie tej afery?

    Odpowiedz
    • 2017.02.16 16:30 Najstarszy syn ks. proboszcza

      No moze wlasnie bylo tak, ze dochodzenie wykazalo, ze IT prosilo o srodki na bezpieczenstwo/modernizacje, a w/w powiedzieli, ze skoro dziala to nie trzeba.

      Odpowiedz
  • 2017.02.16 16:12 Michał

    1) odwiedzałem stronę KNF we wskazanym okresie, ale moje IP należy do puli operatora Internetowego (Internet w domu), nie znalazłem śladów wymienionych plików na komputerze, czy jeszcze coś mogę zrobić, aby zweryfikować czy mój komputer został dotknięty infekcją?

    2) czy wyłączenie wtyczek (opcja „nigdy nie aktywuj” w Firefox, poprzednio było „pytaj o aktywację” – zwykle nie pozwalam…) skutecznie chroni przed takimi zagrożeniami?

    Odpowiedz
    • 2017.02.16 21:03 Dante

      Jesteś bezpieczny

      Odpowiedz
  • 2017.02.16 18:25 Jonasz

    czy to nie byłoby dziwne ? Tak się natrudzić żeby sobie netcata zainstalować ?

    Odpowiedz
  • 2017.02.17 12:07 SS_Everpopular

    jak wy kur*a nic nie rozumiecie!
    Shame! shame! shame!

    Odpowiedz
  • 2017.02.20 19:27 echo

    Ogólnie sądzę że srservice.dll to nie jest RAT, i czekam aż stanie się to modne.
    Ściślej mówiąc RAT to nie jest główna funkcjonalność tego malware.
    Jest on zbyt duży, zbyt złożony i infekuje pamięć procesów użytkowników sesji RDP.
    Gdyby jedyną rzeczą jaką robi srservice.dll działając w pewnych wypadkach w przestrzeni lsass.exe było realizowanie zdalnego dostępu (tu już powinna się zapalić czerwona lampka ! Poco infekować lsass lub działać w ramach usługi systemowej jeżeli chcemy tylko back-connecta) to całe te injecty w procesy użytkowników zdalnych (tu druga czerwona lampka :)) byłby bezsensu.
    Tak więc sądzę że analizy które się pojawiły skupiają się na funkcjonalności w pewnym sensie drugorzędnej

    Odpowiedz
    • 2017.02.20 19:29 Adam

      Może masz ochotę podzielić się szczegółami swojej analizy? Łamy czekają.

      Odpowiedz
      • 2017.02.21 19:50 echo

        może kiedyś, ale dziękuję za propozycje

        Odpowiedz

Zostaw odpowiedź do Adam

Jeśli chcesz zwrócić uwagę na literówkę lub inny błąd techniczny, zapraszamy do formularza kontaktowego. Reagujemy równie szybko.

Techniczna analiza scenariusza przebiegu ataku na polskie banki

Komentarze