W niektórych artykułach pojawiły się doniesienia, że za ataki odpowiedzialny jest wirus Wiper. Jednak, ataki te nie pozostawiły po sobie żadnych próbek, co poddało w wątpliwość te rewelacje.
Eksperci z International Telecommunication Unit (ITU) zajęli się tymi incydentami i poprosili Kaspersky Lab o pomoc w przeprowadzeniu dochodzenia i zbadaniu wpływu, jaki mógł mieć atak tego szkodliwego oprogramowania.
Po kilku tygodniach analizy nie znaleźliśmy żadnego szkodliwego kodu, który mógłby zostać wykorzystany atakach przypisywanych Wiperowi. Badania nie poszły jednak na marne – to właśnie w trakcie tej analizy wykryliśmy finansowaną rzez rząd kampanię cyberszpiegowską, znaną obecnie jako Flame oraz Gauss.
Naszym zdaniem Wiper był oddzielnym szczepem szkodliwych programów, niezależnym od Flame’a. Sam Flame był wysoce zaawansowaną platformą do przeprowadzania ataków, jednak nie wykryliśmy w nim żadnego destrukcyjnego zachowania. Biorąc pod uwagę złożoność Flame’a można przypuszczać, że został on zaprojektowany z myślą o długoterminowej inwigilacji, a nie do przeprowadzania bezpośrednich ataków mających na celu blokowanie systemów. Oczywiście, zawsze możliwe jest, że ostatnim etapem inwigilacji było dostarczenie modułu takiego jak Wiper, jednak nie natrafiliśmy na żaden ślad takiej aktywności.
Zatem, po kilku miesiącach, dalej zadajemy sobie pytanie: Czym jest ten Wiper?
Podczas naszego kwietniowego dochodzenia dotyczącego tajemniczego ataku mieliśmy możliwość przeanalizowania kilku obrazów dysków twardych, które były zaatakowane przez Wipera. Możemy teraz z pewnością stwierdzić, że incydenty rzeczywiście miały miejsce, a stojące za nim szkodliwe oprogramowanie istniało w kwietniu 2012 r. Badania ujawniły także, że bardzo podobne ataki wystąpiły w grudniu 2011 r.
Większość ataków miała miejsce w ostatnich 10 dniach miesiąca (między 21 a 30 kwietnia), jednak nie możemy potwierdzić, czy miało to związek ze specjalną funkcją, której zadaniem byłoby aktywowanie szkodnika w określone dni.
Twórcy Wipera byli bardzo ostrożni i zniszczyli wszelkie dane, które mogłoby zostać wykorzystane do śledzenia tych incydentów. W wyniku tego, we wszystkich analizowanych przez nas przypadkach nie pozostały prawie żadne ślady aktywności Wipera. „Prawie żadne ślady”, ponieważ cyberprzestępcy pozostawili pewne informacje szczątkowe, które pozwoliły nam lepiej zrozumieć naturę tych ataków.
Z kilku zniszczonych systemów udało nam się odzyskać kopię gałęzi rejestru. Nie zawierała ona wprawdzie żadnych szkodliwych sterowników ani elementów autostartu, jednak po przeanalizowaniu obszaru, w którym znajdowały się usunięte wpisy znaleźliśmy coś ciekawego. Oto, co udało nam się zidentyfikować:
22 kwietnia – tuż przed zamknięciem badanego systemu – pewien bardzo specyficzny klucz rejestru został utworzony, a następnie usunięty. Klucz ten dotyczył usługi o nazwie “RAHDAUD64” i wskazywał na plik o nazwie “~DF78.tmp” znajdujący się w folderze “C:\WINDOWS\TEMP”.
Od razu zauważyliśmy, że dokładnie taki format nazw plików został wykorzystany przez autorów Duqu (http://www.viruslist.pl/find.html?objs=vlweblog&words=duqu). Co więcej, nazwę Duqu nadał węgierski badacz Boldizsár Bencsáth z CrySyS Lab po natrafieniu na pliki z nazwami “~dqXX.tmp” (http://www.crysys.hu/publications/files/bencsathPBF11duqu.pdf).
Próbowaliśmy odzyskać plik “~DF78.tmp” z dysku, jednak okazało się, że fizyczny obszar, na którym się on znajdował, został wypełniony „śmieciami”.
W kilku analizowanych przez nas systemach zauważyliśmy taki sam schemat „czyszczenia”: tworzona jest usługa o nazwie “RAHDAUD64”, która jest usuwana natychmiast przed przeprowadzeniem czyszczenia, a następnie zajmowane przez nią miejsce jest nadpisywane losowymi danymi. Usługa wskazywała na różne nazwy plików, takie jak “~DF11.tmp” oraz “~DF3C.tmp”. Możliwe jest zatem, że nazwy plików były losowe.
Kolejną cechą szczególną procesu czyszczenia był charakterystyczny wzór wykorzystywany do usuwania plików z dysku:
Większość plików, które zostały usunięte, zawierała określony wzór, który ciągle się powtarzał. Co ciekawe, procedura nie nadpisywała całego pliku. W pewnych przypadkach niektóre fragmenty pliku pozostały nietknięte, jednak na samym początku zawsze niszczone były nagłówki. Zależało to najprawdopodobniej od rozmiarów plików. Algorytm czyszczenia został zaprojektowany z myślą o jak najszybszym niszczeniu tak wielu plików, jak to możliwe.
W oparciu o wzór, który był wykorzystywany do czyszczenia, a także dzięki Kaspersky Security Network (KSN) udało nam się zgromadzić statystyki dotyczące zniszczonych plików.
Podczas próby zrekonstruowania algorytmu Wipera odkryliśmy następującą sekwencję:
Czyszczenie dysku o pojemności setek gigabajtów może trwać kilka godzin. Zatem, twórcy szkodliwego programu przygotowali swój algorytm bardzo precyzyjnie, aby osiągnąć maksymalną wydajność. Spójrzmy na przykład na poniższy dysk wyczyszczony przez Wipera. Użyliśmy reprezentacji statystycznej (entropia Shannona w blokach po 256 KB) aby zwizualizować entropię na dysku. Jaśniejsze obszary oznaczają wyższą entropię, a ciemniejsze – niższą. Obszary wyświetlane na czerwono posiadają bardzo wysoką entropię i są to dane o dużym stopniu losowości.
Jak widać, Wiperowi udało się zniszczyć większość zawartości dysku. W górnej części obrazu można także zauważyć pasek wypełniony czerwonymi sektorami – to miejsce zostało wyczyszczone wyjątkowo starannie. Nie widać tutaj żadnego konkretnego wzorca – znaczna cześć dysku została wypełniona kompletnie bezużytecznymi danymi. Jasne jest, że za priorytet czyszczenia obrano początek dysku, następnie jego środkową część – chwilę po tym system był już całkowicie martwy.
Inny widok uzyskaliśmy przyglądając się sektorom, które zostały wypełnione znanymi już wzorami “%PNG / iHDR”. Czerwone pola oznaczają bloki sektorów, które zostały nadpisane tym wzorem:
Jak widać, Wiper wykonał swoje działanie na ponad 75% powierzchni dysku, w wyniku czego większość danych została bezpowrotnie zniszczona.
W pewnych przypadkach Wiper zawiódł – analizowaliśmy jeden 64-bitowy system, na którym szkodliwy program nie mógł się uruchomić. Wykryliśmy dwa pliki w folderze %TEMP%, które zostały nadpisane znanym wzorem PNG/iHDR, jednak reszta dysku pozostała nietknięta:
Zakładamy, że te dwa pliki – spośród tysięcy innych znajdujących się w folderze %TEMP% - musiały zostać zniszczone, ponieważ zawierały ważne dane związane z atakiem Wipera. W innym analizowanym przez nas systemie, poza plikami wymienionymi powyżej, całkowicie zniszczone zostały także pliki “~DF820A.tmp” oraz “~DF9FAF.tmp” (o rozmiarze około 512 bajtów).
Co ciekawe, w pewnych systemach zauważyliśmy, ze wszystkie pliki PNF w folderze INF systemu Windows były czyszczone z wyższym priorytetem niż inne obiekty. Po raz kolejny widzimy powiązanie z Duqu i Stuxnetem – szkodniki te trzymały swój główny kod w zaszyfrowanych plikach “.PNF”.
Jeżeli celem atakujących było upewnienie się, że Wiper nigdy nie zostanie wykryty, logicznym było czyszczenie w pierwszej kolejności składników szkodliwego programu, a dopiero później zajęcie się innymi danymi.
Podczas szukania tego nieuchwytnego szkodliwego programu natrafiliśmy na coś zupełnie nowego. Podejrzewaliśmy, ze Wiper wykorzystywał nazwy plików takie jak “~DF*.tmp” lub “~DE*.tmp” w folderze TEMP, zatem zaczęliśmy się im przyglądać przy użyciu danych z KSN. Doprowadziło to do wykrycia przez nas nienaturalnie dużej liczby komputerów zawierających ten sam plik: ~DEB93D.tmp:
Format nazwy wskazywał, że plik może być częścią platformy Tilded i może być powiązany z Duqu i Stuxnetem. Plik wyglądał na zaszyfrowany, jednak szybko zwróciliśmy uwagę na pewną prawidłowość:
Duqu (3 listopada 2010):
00: ED 6F C8 DA 30 EE D5 01
~DEB93D:
00: 6F C8 FA AA 40 C5 03 B8
Zupełnie przypadkowo zauważyliśmy, że plik rozpoczynał się od bajtów “6F C8”, które były także obecne w zaszyfrowanej postaci w początkowej części głównego kodu Duqu – ładowanego przez sterownik skompilowany 3 listopada 2010 r. Gdyby nie to spostrzeżenie, prawdopodobnie nigdy nie zwrócilibyśmy uwagi na plik ~DEB93D.tmp, ponieważ jego zawartość wygląda jak zwykłe śmieci.
Użyty algorytm był słaby i wyglądało na to, że wzór powtarza się co 4096 bajtów – dzięki temu udało nam się odszyfrować zawartość przy użyciu kryptoanalizy statystycznej - typowej metody wykorzystywanej podczas analizy szkodliwego oprogramowania. Po odszyfrowaniu pliku zauważyliśmy coś, co wyglądało jak logi procedury nasłuchującej. Idąc dalej tym tropem, wykryliśmy kolejne pliki zmodyfikowane tego samego dnia – takie jak “mssecmgr.ocx”, “EF_trace.log” lub “to961.tmp”. Reszta jest już historią – właśnie tak wykryliśmy Flame’a.
Nie ma wątpliwości, że istniał szkodliwy program znany jako Wiper, który atakował komputery w Iranie (i być może w innych częściach świata) do końca kwietnia 2012 r.
Szkodnik ten był tak dobrze napisany, że gdy tylko został aktywowany, z danych nie pozostawało nic wartościowego. Zatem, mimo że dotarliśmy do śladów infekcji, szkodliwy program pozostaje nieznany. Nie zaobserwowaliśmy żadnych dodatkowych incydentów, które wykorzystywałyby schemat postępowania Wipera.
Analizy
Blog