Wielokrotnie informowaliśmy już o nowym zagrożeniu dla polskich użytkowników bankowości elektronicznej, które nazwaliśmy VBKlip. Przypominając, jest to rodzaj malware’u, którego działanie polega na podmianie numeru rachunku bankowego skopiowanego do schowka. W ten sposób, gdy np. opłacamy fakturę kopiując numer konta i następnie go wklejając, wysyłamy przelew na inne konto niż zamierzaliśmy. W tym wpisie przyjrzymy się temu zagrożeniu z perspektywy ostatnich kilku miesięcy, a także przedstawimy szczegółową jego analizę. Uważamy, że zagrożenie wciąż jest istotne, ponieważ wciąż dostajemy zgłoszenia od użytkowników, którzy zostali zainfekowani tym złośliwym oprogramowaniem i w wyniku jego działania stracili środki na koncie.

VBKlip.NET

Po przeanalizowaniu kilkudziesięciu próbek malware’u, byliśmy w stanie wydzielić dwie różne aktywne rodziny: jedna napisana w .NET i jedna napisana w Visual Basic 6. Najprawdopodobniej są one autorstwa dwóch różnych osób, bądź grup.

Pierwszą rodziną zagrożenia VBKlip jest grupa złośliwego oprogramowania napisana w frameworku .NET. Z naszych informacji wynika, iż rozprzestrzenia się za pomocą istniejących botnetów (np. Andromeda) i jest uruchamiana i instalowana bez wiedzy użytkowników. Sam malware jest bardzo prosty w swej budowie. Zawartość schowka jest porównywana z dwoma popularnymi standardami podawania numerów rachunków bankowych. Następnie, jeśli porównanie zakończy się sukcesem, numer znajdujący się w schowku jest podmieniany na numer na stałe wpisany w kodzie źródłowym. Złośliwe oprogramowanie nie wykonywało żadnej komunikacji sieciowej, ani nie tworzyło żadnych kluczy rejestru.

Kod złośliwego oprogramowania definiuje jedną formatkę (nazwaną Form1), która zawiera jeden komponent typu Timer, którego celem jest wykonanie określonej funkcji co zadany czas. Aby formatka (okienko) nie była wyświetlana ustawiano jeden z jej rozmiarów na 0 oraz wyłączano pokazywanie okienka na pasku zadań. Po opublikowaniu wpisu na naszym blogu na temat tego zagrożenia producenci programów antywirusowych zaczęli tworzyć sygnatury na ten rodzaj malware.
Z drugiej strony, autor złośliwego oprogramowania zaczął podejmować działania kontrofensywne. Polegały one na dodawaniu kolejnych przycisków lub etykiet do niewidocznej formatki. Najczęściej wystarczyło to, aby zbić liczbę wykryć w serwisie VirusTotal z kilkunastu do mniejszej niż 5. Dodany był też kod przepisany z podręcznika programowania zaprezentowany na listingu poniżej.

Udało nam się ustalić, iż autor złośliwego oprogramowania najprawdopodobniej używa komputera z systemem Windows Vista lub nowszym z konta użytkownika nazwanego Thomas. Najprawdopodobniej zna również język polski, na co wskazują nazwy plików wykonywalnych, w których znajdował się malware. Zadbał także o to, aby kolejne wersje udawały aktualizacje popularnych programów. Uzyskiwał to dodając ikony oraz nazwy takiego oprogramowania jak: Adobe Flash Player, Facebook Chat czy Java. Łącznie przeanalizowaliśmy kilkadziesiąt próbek tego rodzaju VBKlip.

VBKlip w Visual Basic 6

Wersja napisana w Visual Basic nie zmienia się znacząco. Zostało ono napisane przez osobę, która swobodnie posługuje się językiem polskim. Od pewnego czasu złośliwe oprogramowanie wykorzystuje komunikację z serwerem C&C w celu przekazania numeru konta słupa. Również wysyła wiadomości e-mail (korzystając z protokołu SMTP) do autora z informacją o wszystkich podmianach numerów kont. Nic nie wskazuje na to, że autorem tej wersji jest ta sama osoba, która jest autorem wersji w .NET.

Złośliwe oprogramowanie rozprzestrzeniało się za pomocą wiadomości typu spear phishing co najmniej dwóch typów. Pierwszy typ to wiadomości kierowane do sprzedawców Allegro. Treść wiadomości sugerowała, że w załączonym pliku (albo archiwum zip, albo po prostu plik wygaszacza ekranu scr) znajdowały się zdjęcia reklamowanego przedmiotu, który był wcześniej rzekomo zakupiony. Nazwa pliku kończyła się na .jpg, a jego ikona sugerowała, że był to obraz. Opis przedmiotu był dopasowany do tego, co oferował dany sprzedający. Drugim typem e-mail były wiadomości wysyłane do różnych firm, które rzekomo zawierały fakturę w formacie PDF. Ikona oraz końcówka nazwy pliku sugerowała, że był to plik PDF. Nazwy plików również były spersonalizowane, aby wskazywać na odbiorcę.

Malware ten, po uruchomieniu, rozpakowywał plik zip do katalogu tymczasowego (%TEMP%). Jeśli była to wersja, która miała udawać fakturę, to dodatkowo był uruchamiany czytnik plików PDF, który miał otworzyć pusty plik. Adobe Reader raportuje taki plik jako „uszkodzony”, co miało przekonać użytkownika, że otworzył niepoprawnie stworzoną fakturę.

Następnie, w celu uzyskania numeru konta słupa, który ma zostać wpisany do schowka, VBKlip kontaktował się z serwerem C&C. Serwer, w odpowiedzi przesyłał tylko numer konta. W przypadku, gdy kontakt z serwerem nie był możliwy VBKlip używał zapisanego w nim na stałe numeru konta. Serwer był tak skonfigurowany, aby odpowiadać tylko na zapytania z poprawnym nagłówkiem User-Agent, aby być pewnym, że pochodzą one ze złośliwego oprogramowania.

Dodatkowym kanałem komunikacji był protokół SMTP. Za pomocą wiadomości mail z adresu oraz na adres w domenie vfemail.net przesyłana była informacja o infekcji komputera zawierająca czasami (w zależności od próbki) listę procesów, które działały na danej maszynie. Dodatkowo, co pewien czas, były przekazywane informacje o aktywności bota. Informacje te zawierały dane o stronach, z których zostały skopiowane numery kont (lub na które zostały wklejone) wraz z identyfikatorem serwisu transakcyjnego banku. Identyfikator ten był rozpoznawany na podstawie tytułu strony w przeglądarce. Następujące części tytułów okien były rozpoznawane:

• Alior
• eBG
• E-BG
• Bank Ochrony
• Agricole
• WBK S
• eurobank
• GETIN Bank
• ING Bank
• nteligo [sic!]
• INVEST-BANK
• iPKO
• mBank
• MultiBank
• Pekao24
• Pocztowy
• Raiffeisen

Jeśli tytuł serwisu transakcyjnego nie został rozpoznany, zapisywano go jako nieznany (identyfikator 0). Dodatkowo eBG oraz E-BG były zapisywane jako ten sam bank.

Oprogramowanie składa się z kilku komponentów, nazwanych podobnie do programów z systemu Windows. Każdy z nich odpowiada za inną funkcjonalność. Drzewo komponentów, uzyskane w wyniku uruchomienia jednej z próbek jest zaprezentowane poniżej (proces explorer.exe jest oryginalnym procesem systemu Windows).



Dzięki zastosowaniu kilku komponentów, nawet mimo wykrycia przez oprogramowanie antywirusowe jednego z komponentów, pozostałe mogą wciąż działać. Najlepszym przykładem jest wykrywanie przez niektóre antywirusy komponentu odpowiedzialnego za komunikację sieciową i zabijanie odpowiedniego procesu. Jednak komponent odpowiedzialny za podmianę numeru rachunku nie jest wykrywany, co powoduje, że podmiana wciąż zachodzi, mimo, że nie są już przesyłane raporty. Najważniejsze komponenty przedstawiono poniżej.

atidrv32.exe

Pierwszy z komponentów jest odpowiedzialny za logowanie. Zajmuje się on tłumaczeniem nazw banków na identyfikatory, śledzeniem gdzie jest wklejany numer konta oraz sporządzaniem raportów z aktywności użytkownika. Wszystkie te raporty zapisywane są do pliku tekstowego msf32drv.dll. Logowane informacje zawierają między innymi:

• identyfikator banku (numeryczny) oznaczony nrB,
• przeglądarka oznaczona Br,
• nazwa komputera (jako nazwa nadawcy wiadomości e-mail),
• nazwa użytkownika (jako nazwa odbiorcy),
• czas lokalny i wersja VBKlip (jako tytuł maila),
• adres URL oraz tytuł okna przeglądarki (zarówno w przypadku kopiowania jak i wklejania, jako URL oraz Sub),
• wybrane cyfry numeru konta słupa (jako Ref1).

winlog.exe

Ten komponent jest odpowiedzialny za podmianę numeru konta. Sprawdza on m.in. czy okno, do którego jest wklejany numer konta nie zawiera ciągu znaków notatnik, notepad albo word. Zapobiega to stosowaniu prostej metody sprawdzenia infekcji – skopiowaniu i wklejeniu numeru konta w programie Notatnik, MS Word czy też WordPad. Dodatkowo, odszyfrowuje on w pamięci komunikaty z C&C, tak aby na dysku nigdy nie był obecny numer konta słupa. Komunikacja jest szyfrowana za pomocą szyfru podstawieniowego – jednej cyfrze numeru konta może odpowiadać jedna z czterech liter ASCII. Komponent ten też loguje wszystkie użycia schowka systemowego i zapisuje je wraz z nazwą aktualnie aktywnego okna.

taskmgr.exe

Komponent odpowiedzialny za komunikację sieciową oraz tworzenie drzewa procesów. Jest on najczęściej wykrywany przez systemy antywirusowe. Jak wcześniej zaznaczono, jego wyłączenie nie powoduje wyłączenia podmiany numeru konta, za którą odpowiedzialny jest winlog.exe.
Komponent ten odpowiada również za uruchomienie oraz utrzymanie konkretnego drzewa procesów. W ten sposób dba o to, żeby, nawet jeśli użytkownik wyłączy jeden komponent, to zostanie on ponownie uruchomiony. Jest tu pewnego rodzaju socjotechnika – użytkownik nie wyłączy procesu o nazwie taskmgr.exe z poziomu Menadżera Zadań, ponieważ będzie myślał, że jest to właśnie Menadżer Zadań. Odróżnienie tego komponentu od oryginalnego Menadżera jest jednak możliwe: komponent jest 32-bitowy oraz ma opis taskmgr v 1.012.
Dodatkową funkcjonalnością jest sprawdzenie odpowiedzi od C&C. W zależności od adresu URL C&C odpowiedź powinna zawierać pewne znaki kontrolne na końcu zaszyfrowanego numeru konta. taskmgr.exe sprawdza czy odpowiedź jest poprawnego formatu, a następnie zapisuje ją (wciąż zaszyfrowaną) do pliku msgrid64.cpx. Pozostałe komponenty korzystają z tego pliku w celu sprawdzenia numeru konta słupa. Oczywiście taskmgr.exe odpowiedzialny jest też za wysyłanie raportów korzystając z protokołu SMTP.

ms32sound.exe

Ostatni z komponentów, których działania pilnuje taskmgr.exe odpowiada za logowanie wszystkich naciśniętych klawiszy. Następnie są one zapisywane w zakodowany sposób w pliku msgrid.dll. Kodowanie stosowane w kilku miejscach programu opiera się na wcześniej zdefiniowanym słowniku, który tłumaczy litery ASCII na cyfry 0-9. Każdej cyfrze odpowiadają cztery litery. O ile kodowanie numerów rachunku jest w miarę oczywiste, o tyle kodowanie ciągów znaków bądź wciśniętych klawiszy jest troszkę bardziej skomplikowane. Znak ASCII reprezentowany jest w postaci trzycyfrowej liczby w systemie dziesiętnym (np. A -> 065). Następnie cyfry są zamieniane miejscami (cyklicznie w prawo), pierwsza jest na drugim miejscu, druga na trzecim, a trzecia na pierwszym (np. 065 -> 506). Następnie takie trzy cyfry są kodowane za pomocą wspomnianego słownika.

VBKlip – nowi gracze, czy tylko nowe techniki?

W ostatnich dniach zaobserwowaliśmy nowe próbki VBKlip. Po pierwsze, wersja w .NET została zaciemniona, aby utrudnić analizę. Udaje ona również plik programu Word i po uruchomieniu otwiera program Notatnik. Wskazuje to, że albo autor zmienił strategię dystrybucji malware i zakupił odpowiedni packer, albo ktoś inny skorzystał z tego samego pomysłu.

Z kolei VBKlip w Visual Basic używa również innego serwera C&C. Jednak nie tylko ta zmiana jest istotna – zmienione zostały nazwy komponentów, natomiast serwer C&C był źle skonfigurowany. Nie akceptował (błędnego zresztą) nagłówku HTTP Accept Language przez co złośliwe oprogramowanie nie mogło poprawnie funkcjonować. Jednak konta mailowe były wciąż założone w serwisie vfemail.net.

Te fakty mogą wskazywać, że albo autor malware oddał bądź sprzedał swoje oprogramowanie komuś innemu albo po prostu postanowił przebudować botnet.

Podsumowanie

VBKlip jest wciąż realnym zagrożeniem, pomimo kampanii informacyjnej. Oczywiście ma mniejszą skuteczność niż na początku istnienia, ale wciąż są użytkownicy, którzy zostali przez niego okradzeni. Dlatego radzimy wszystkim sprawdzanie numeru konta, na który wysyłają przelew. W przypadku korzystania z haseł jednorazowych za pomocą SMS najlepiej jest sprawdzić numer konta otrzymany w wiadomości SMS z numerem konta na który chcieliśmy przelać pieniądze. Oczywiście, wciąż istnieje prawdopodobieństwo, że osoba, która wysłała nam maila z fakturą użyła schowka, aby skopiować numer rachunku ze strony banku na fakturę.