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.
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.
Komentarze
Z tego co wiem do dzisiaj nie ma stanowiska KNF w tej sprawie…
Jest, zaczyna się od „stwierdzono próbę ataku”…
„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….
Malo tego, ktos ma w d*pie czy userzy instaluja sobie takie gowna jak Flash czy Silverlight.
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.
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.
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ą…
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 :)
silverlight juz sie raczej nie zaktualizuje bo nie jest wiecej rozwijany a eol juz tuz tuz.
https://www.microsoft.com/getsilverlight/locale/en-us/html/Microsoft%20Silverlight%20Release%20History.htm
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?
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.
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?
Jesteś bezpieczny
czy to nie byłoby dziwne ? Tak się natrudzić żeby sobie netcata zainstalować ?
jak wy kur*a nic nie rozumiecie!
Shame! shame! shame!
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
Może masz ochotę podzielić się szczegółami swojej analizy? Łamy czekają.
może kiedyś, ale dziękuję za propozycje