miniFlame zwany SPE: "Elvis i jego przyjaciele"

• Wprowadzenie
• Streszczenie
• Historia odkrycia "SPE"
  • Połączenia pomiędzy Flamem i "SPE"
  • Połączenia pomiędzy Gaussem i "SPE"
• Oś czasu "SPE"
• Przepływ operacji "SPE"
• Informacje o wersjach "SPE"
• Statystyki infekcji (dane KSN)
• Statystyki leja
• "Icsvnt32.ocx" (główny moduł)
  • Funkcja eksportu "RegisterService"
• "Icsvntu32.ocx" (infekcja USB)
  • "DllMain"
  • Procedura gromadzenia danych
  • Procedura samousuwania
• Wnioski
• Referencje

Wprowadzenie

Podczas analizy szkodliwego oprogramowania Flame [1], które wykryliśmy w maju 2012 r., nasze badania zidentyfikowały cechy odróżniające od siebie poszczególne moduły tego szkodnika. Rozważając te funkcje modułowe wykryliśmy, że pierwszy wariant robaka Stuxnet [4] w 2009 r. zawierał moduł, który został stworzony w oparciu o platformę Flame. Potwierdziło to nasze domniemania, że istniała jakaś forma współpracy między grupami, które rozwinęły projekt Flame i platformę Tilded (Stuxnet / Duqu) [5].

Opierając się na wynikach szczegółowej analizy Flame'a kontynuowaliśmy poszukiwania nowych, nieznanych komponentów szkodnika. Bardziej szczegółowe badania, przeprowadzone w czerwcu 2012 r., zaowocowały wykryciem kolejnego, sponsorowanego przez rząd i dotychczas nieznanego, szkodliwego oprogramowania, któremu nadaliśmy nazwę Gauss [2]. Gauss używał konstrukcji modułowej, przypominającej tę znaną z Flame'a, był podobnie kodowany, korzystał z podobnego do Flame'a systemu komunikacji z serwerami centrum kontroli (C&C) i posiadał kilka pomniejszych funkcjonalności do złudzenia przypominających funkcje Flame'a. Bazując na zewnętrznych obserwacjach i publicznie dostępnych informacjach, opublikowaliśmy naszą własną analizę serwerów centrum kontroli Flame'a. Pomogła ona w poznaniu rozkładu geograficznego serwerów C&C i sposobu ich rejestracji. We wrześniu 2012 r. opublikowaliśmy nowe informacje, które zostały zebrane podczas intensywnego śledztwa prowadzonego we współpracy z firmami Symantec, ITU-IMPACT i CERT-Bund/BSI.

Przeprowadzona analiza wykazała, że kod C&C może zrozumieć kilka protokołów komunikacyjnych i porozumiewać się z różnymi "klientami" lub innym szkodliwym oprogramowaniem:

• OldProtocol
• OldProtocolE
• SignupProtocol
• RedProtocol (protokół występuje w kodzie C&C, lecz nie został jeszcze w pełni zaimplementowany)

Bliższe spojrzenie na sposoby obsługi tych protokołów ujawniło cztery różne typy klientów o nazwach kodowych: "SP", "SPE", "FL" i "IP". Opierając się na logice analizowanego kodu C&C potwierdziliśmy, że szkodliwe oprogramowanie Flame zostało zidentyfikowane jako klient typu "FL". Oczywiście, w momencie tego odkrycia oznaczało to, że istnieją jeszcze trzy niewykryte narzędzia do cyberszpiegostwa lub cybersabotażu, stworzone przez tych samych autorów co "FL" ("SP", "SPE" i "IP").

Zależności klientów i protokołów komunikacyjnych wykryte w kodzie C&C

Przy współudziale i nieocenionej pomocy ze strony naszych partnerów byliśmy w stanie skonfigurować lej dla Flame'a. W poprzednim artykule [3] opublikowaliśmy statystyki pochodzące z utworzonego dla Flame'a leja. Prawdopodobnie najbardziej interesującą rzeczą jest to, że analizując kod C&C Flame'a byliśmy w stanie podzielić połączenia otrzymywane przez nasz lej na dwie główne kategorie:

• Połączenia OldProtocol (pochodzące od Flame'a);
• Połączenia OldProtocolE (wykorzystywane przez "SPE").

W ten sposób, we wrześniu 2012 r. potwierdziliśmy istnienie "na wolności" co najmniej jednego, nieznanego dotychczas, szkodliwego programu stworzonego w oparciu o platformę Flame.

Wszystko rozpoczęło się na początku lipca 2012 r., gdy wykryliśmy nieduży, ale bardzo interesujący moduł Flame'a. Moduł posiadał wiele cech charakterystycznych dla Flame'a, co sprawiło, iż założyliśmy, że jest to jakaś wcześniejsza wersja tego szkodnika (wszystkie znane warianty Flame'a opatrzone są numerem wersji 2.x). W kolejnych miesiącach nie tylko studiowaliśmy związek tego złośliwego oprogramowania z Flamem, ale natknęliśmy się również na przykłady użycia tego modułu w cyberbroni Gauss (moduł występował jako składnik kontrolowany przez główny moduł Gaussa). Po przeanalizowaniu centrum kontroli Flame'a byliśmy zaskoczeni, że nowo wykryty wariant domniemanego "FL" używa do komunikacji z C&C protokołu "OldProtocolE", który był skojarzony z tajemniczym modułem "SPE". Wreszcie zrozumieliśmy, że nie mamy do czynienia z wtyczką Flame'a, a z kompletnie odrębnym i unikalnym oprogramowaniem, rozpoznawanym przez serwery C&C Flame'a jako "SPE". Niniejszy artykuł opisuje odkrycie szkodnika "SPE" i podaje analizę funkcjonalności tego zagrożenia.

Streszczenie

Szkodliwe oprogramowanie "SPE", które postanowiliśmy nazwać "miniFlame", jest małym, w pełni funkcjonalnym modułem szpiegowskim, zaprojektowanym do kradzieży danych i uzyskiwania bezpośredniego dostępu do zainfekowanych systemów. miniFlame faktycznie został stworzony w oparciu o platformę Flame, lecz zaimplementowano go jako osobny moduł. Może pracować niezależnie od obecności w systemie głównych modułów Flame'a lub jako składnik pracujący pod kontrolą Flame'a.

Wart podkreślenia jest fakt, że miniFlame może być stosowany również w połączeniu z innym programem szpiegowskim – Gaussem. Jak wielu czytelników zapewne pamięta, powstało założenie, że Flame i Gauss były równoległymi projektami, które nie posiadały żadnych wspólnych modułów ani serwerów C&C. Odkrycie miniFlame'a, który może współpracować z oboma wspomnianymi projektami szpiegowskimi, częściowo potwierdza słuszność naszej konkluzji, że wszystkie badane narzędzia cyberszpiegowskie pochodzą z tej samej "cyberzbrojowni".

Najwyraźniej rozwój miniFlame'a rozpoczął się kilka lat temu i był kontynuowany do 2012 r. Na podstawie kodu C&C widać, że protokoły wykorzystywane przez "SP" i "SPE" zostały utworzone wcześniej lub w tym samym czasie, co protokół komunikacyjny używany przez Flame'a ("FL"), tj. przynajmniej w 2007 r. Wierzymy, że deweloperzy miniFlame'a stworzyli dziesiątki różnych modyfikacji tego programu. Jak do tej pory wykryliśmy tylko sześć, datowanych na okres 2010 - 2011 r. W niektórych przypadkach dedykowane serwery C&C kontrolowały wyłącznie operacje z użyciem "SPE". Jednocześnie, niektóre warianty "SPE" pracowały z serwerami, z którymi komunikował się Flame.

Szkodnik miniFlame / SPE różni się od Flame'a i Gaussa znacznie mniejszą liczbą infekcji. Podczas, gdy szacowana przez nas liczba ofiar Flame'a / Gaussa nie jest niższa niż 10 000, "SPE" wykryto na zaledwie kilkudziesięciu systemach w Zachodniej Azji. Oznacza to, że "SPE" jest narzędziem wykorzystywanym do ukierunkowanych ataków na starannie dobrane cele o najwyższym priorytecie, budzące szczególne zainteresowanie napastników.

Kiedy porównamy liczbę infekcji "SPE" z infekcjami rozprzestrzenianymi przez wykryte wcześniej zagrożenia o podobnej strukturze otrzymamy poniższą tabelę:

W przeciwieństwie do Flame'a, w którego przypadku większość incydentów została zarejestrowana w Iranie i Sudanie, oraz Gaussa, który skoncentrowany był na Libanie, "SPE" nie ma jasnej przynależności geograficznej. Uważamy jednak, że wybór krajów zależy od użytego wariantu "SPE". Dla przykładu, modyfikacja znana jako 4.50 występuje głównie w Libanie i Palestynie. Pozostałe warianty szkodnika były rejestrowane w innych krajach, takich jak Iran, Kuwejt czy Katar.

Oryginalny wektor dystrybucji "SPE" nie jest znany. Jednakże, ponieważ wiadomo, że szkodnik działa jako część Flame'a i Gaussa, i że może współdzielić serwery C&C z Flamem, wierzymy, iż w większości przypadków "SPE" był instalowany z serwerów C&C na systemach, które już wcześniej zostały zainfekowane przez Flame'a lub Gaussa. Należy jednak wyraźnie zaznaczyć, że "SPE" nie był obecny na wstępnie zdefiniowanych listach plików, występujących w znanych konfiguracjach Flame'a i nie był usuwany przez moduł "browse32.ocx", który był dystrybuowany przez autorów Flame'a w maju 2012 r. w celu samoczynnej dezinstalacji szkodnika z zainfekowanych systemów.

Historia odkrycia "SPE"

Połączenia pomiędzy Flamem i "SPE"

Flame implementuje ciekawą strukturę konfiguracyjną dla całego systemu złośliwego oprogramowania. Struktura ta jest zorganizowana na takich samych zasadach, jak rejestr systemu Windows. Konfiguracja określa nie tylko listy wszystkich dostępnych modułów i plików, ale również ich parametry, listy plików tymczasowych, listy programów antywirusowych itd. Łączna liczba parametrów, określonych w konfiguracji, może sięgać kilku tysięcy.

Nasza analiza ponad dziesięciu różnych wariantów Flame'a (z których najwcześniejszy jest datowany na 2008 r.) pokazała, że podczas lipca i sierpnia 2010 r. deweloperzy zaimplementowali coś w rodzaju zmiany wersji - z wariantu "A" na wariant "B". Do tego momentu konfiguracja Flame'a obejmowała jedynie pliki z identyfikatorem "A":

SUICIDE.RESIDUAL_FILES.A15 : %COMMONPROGRAMFILES%
\Microsoft Shared\MSAudio\dstrlog.dat
SUICIDE.RESIDUAL_FILES.A14 : %COMMONPROGRAMFILES%\Microsoft 
Shared\MSSecurityMgr\dstrlog.dat
SUICIDE.RESIDUAL_FILES.A13 : %SYSTEMROOT%\Temp\~8C5FF6C.tmp
SUICIDE.RESIDUAL_FILES.A12 : %windir%\system32\mssvc32.ocx
SUICIDE.RESIDUAL_FILES.A11 : %COMMONPROGRAMFILES%\Microsoft
 Shared\MSSecurityMgr\rccache.dat
SUICIDE.RESIDUAL_FILES.A10 : %windir%\system32\winconf32.ocx
SUICIDE.RESIDUAL_FILES.A9 : %windir%\system32\watchxb.sys
SUICIDE.RESIDUAL_FILES.A8 : %windir%\system32\sdclt32.exe
SUICIDE.RESIDUAL_FILES.A7 : %windir%\system32\scaud32.exe
SUICIDE.RESIDUAL_FILES.A6 : %windir%\system32\mssui.drv
SUICIDE.RESIDUAL_FILES.A5 : %windir%\system32\modevga.com
SUICIDE.RESIDUAL_FILES.A4 : %windir%\system32\indsvc32.ocx
SUICIDE.RESIDUAL_FILES.A3 : %windir%\system32\indsvc32.dll
SUICIDE.RESIDUAL_FILES.A2 : %windir%\system32\comspol32.ocx
SUICIDE.RESIDUAL_FILES.A1 : %windir%\system32\comspol32.dll

Identyfikator "B" po raz pierwszy pojawił się w próbkach Flame'a datowanych na dzień 1 sierpnia 2010 r. i był stosowany we wszystkich kolejnych wariantach szkodnika, również w tych ostatnich z roku 2011.

SUICIDE.RESIDUAL_FILES.B9 : %windir%\system32\advnetcfg.ocx
SUICIDE.RESIDUAL_FILES.B8 : %windir%\system32\nteps32.ocx
SUICIDE.RESIDUAL_FILES.B7 : %temp%\~HLV473.tmp
SUICIDE.RESIDUAL_FILES.B6 : %temp%\~HLV927.tmp
SUICIDE.RESIDUAL_FILES.B5 : %temp%\~HLV294.tmp
SUICIDE.RESIDUAL_FILES.B4 : %temp%\~HLV084.tmp
SUICIDE.RESIDUAL_FILES.B3 : %temp%\~KWI989.tmp
SUICIDE.RESIDUAL_FILES.B2 : %temp%\~KWI988.tmp
SUICIDE.RESIDUAL_FILES.B18 : %systemroot%\system32\msglu32.ocx
SUICIDE.RESIDUAL_FILES.B17 : %temp%\~dra53.tmp
SUICIDE.RESIDUAL_FILES.B16 : %temp%\~rf288.tmp
SUICIDE.RESIDUAL_FILES.B15 : %windir%\system32\advpck.dat
SUICIDE.RESIDUAL_FILES.B14 : %windir%\system32\ntaps.dat
SUICIDE.RESIDUAL_FILES.B13 : %windir%\system32\soapr32.ocx
SUICIDE.RESIDUAL_FILES.B12 : %windir%\system32\rpcnc.dat
SUICIDE.RESIDUAL_FILES.B11 : %windir%\system32\boot32drv.sys
SUICIDE.RESIDUAL_FILES.B10 : %windir%\system32\ccalc32.sys
SUICIDE.RESIDUAL_FILES.B1 : %temp%\~HLV751.tmp
SUICIDE.RESIDUAL_FILES.B : %temp%\~DFL542.tmp

Oczywiście staraliśmy się znaleźć wszystkie pliki z nazwami, które były wykorzystywane we Flamie od 2008 r. Na początku czerwca 2012 r. natrafiliśmy na plik "watchxb.sys" (SUICIDE.RESIDUAL_FILES.A9 : %windir%\system32\watchxb.sys), który jest jednym z plików Flame'a "A", używanym do sierpnia 2010 r. Kiedy przeanalizowaliśmy znaleziony plik "watchxb.sys", byliśmy co najmniej zaskoczeni.

Plik ten został zaszyfrowany z wykorzystaniem prostego algorytmu XOR 0xFF. "watchxb.sys" to plik konfiguracyjny skonstruowany podobnie do plików konfiguracji Flame'a: określa on swoje własne pliki składowe, klucze rejestru, listy programów antywirusowych i nazwy plików tymczasowych. Pośród wspomnianych nazw plików natrafiliśmy na plik "icsvnt32.ocx", z którym wcześniej nie mieliśmy do czynienia.

Nigdy wcześniej nie napotkaliśmy pliku o takiej nazwie w żadnym ze znanych modułów Flame'a. Aż do tego momentu plik nie był używany w żadnej znanej konfiguracji Flame'a i co więcej - nie figurował on na liście plików przeznaczonych do samousunięcia (przypominamy, że listę tę zawierał moduł "browse32.ocx"). Prowadząc dalsze poszukiwania natrafiliśmy na plik "icsvnt32.ocx". Stało się to w tym samym czasie, w którym prowadziliśmy analizę kolejnego narzędzia cyberszpiegowskiego - Gaussa. Miejsce, w którym odkryliśmy plik, było jednak zaskakujące.

Połączenia pomiędzy Gaussem i "SPE"

Gauss posiada budowę modułową. Liczba i kombinacja modułów może być zmienna w zależności od natury infekowanych systemów. W trakcie naszych badań odkryliśmy następujące moduły: Cosmos, Godel (Kurt), Tailor, McDomain, UsbDir, Lagrange, Gauss i ShellHW. Konfiguracja specyficznego połączenia modułów dla każdego systemu opisywana jest w specjalnym kluczu rejestru. Technika ta, jak również sama struktura konfiguracji jest podobna do tej zastosowanej w Stuxnecie / Duqu (przechowywanie konfiguracji w rejestrze Windows) i Flamie (struktura konfiguracji).

Stworzyliśmy specjalną procedurę wykrywania, która pomogła nam w odkryciu różnych konfiguracji Gaussa, w zależności od ustawień rejestru na zainfekowanych maszynach. W sumie wykryliśmy około 1700 takich konfiguracji, które ujawniły obraz propagacji poszczególnych modułów. I w tym miejscu po raz kolejny doznaliśmy zaskoczenia. Na niektórych systemach w Libanie, konfiguracja Gaussa, oprócz wymienionych powyżej modułów, zawierała jeden dodatkowy moduł o nazwie kodowej "John".

We wszystkich tych nietypowych konfiguracjach Gaussa nowo odkryty moduł wskazywał na plik %systemroot%\system32\icsvnt32.ocx i był wywoływany przez funkcję "RegisterService".

Gauss 1.0.8
ShellNotifyUser
ShellNotifyUserEx
SetWindowEvent
InitShellEx
%systemroot%\system32\winshell.ocx
%systemroot%\temp\ws1bin.dat
Godel
InitCache
RevertCache
ValidateEntry
CreateEntry
%windir%\system32\dskapi.ocx
%temp%\~gdl.tmp
John
RegisterService
%systemroot%\system32\icsvnt32.ocx
UsbDir
%windir%\system32\smdk.ocx
%temp%\~mdk.tmp

Zrzut ekranu odszyfrowanego klucza rejestru w pliku konfiguracyjnym Gaussa, który używał modułu "John":

 

Dało to potwierdzenie faktu, że "icsvnt32.ocx" jest unikalnym modułem, możliwym do zastosowania zarówno we Flamie, jak i w Gaussie. Jest to ogniwo, które mimo iż pozostaje niezależnym komponentem, to jednak mocniej łączy ze sobą oba projekty cyberszpiegowskie. "icsvnt32.ocx" używa swoich własnych, dedykowanych serwerów C&C, ale potrafi też współdzielić serwery kontroli z Flamem.

Oś czasu "SPE"

W sumie wykryliśmy sześć różnych wariantów "SPE". Wszystkie z nich powstały w okresie od 1 października 2010 r. do 1 września 2011 r. Dla trzech z tych wersji "SPE" wykryliśmy również tzw. moduły "U", odpowiedzialne za interakcję szkodnika z dyskami USB.

 

Powyższa oś czasu pokazuje, że istniała tylko jedna instancja "SPE" (4.50), dla której moduł "U" został utworzony w innym czasie, niż moduł główny.

Istnienie wersji "SPE" wcześniejszych niż 4.x i starszych niż 5.x nie zostało dotychczas potwierdzone. Możliwe jest, że wcześniejsze wersje "SPE" to faktycznie klient typu "SP", który również był obsługiwany przez serwery C&C. Zakładając, że rozwój każdej głównej wersji programu trwał około jednego roku, wersja 1.x mogła powstać już w roku 2007. W momencie pisania tego artykułu, "na wolności" najbardziej rozprzestrzeniony jest wariant o numerze wersji 4.50 (zgodnie ze statystykami z Kaspersky Security Network). Analizując informacje z wielu pośrednich źródeł możemy przypuszczać, że dalszy rozwój programu przerwano po opublikowaniu wersji o numerze 5.00.

Przepływ operacji "SPE"

Po szczegółowym przebadaniu modułów "SPE", logiki operacji i możliwości serwerów C&C, zdołaliśmy stworzyć schemat ogólnego algorytmu, pokazujący w jaki sposób "SPE" działa na zainfekowanym systemie:

 

Pierwszy etap polega na wstępnej infekcji całego systemu. Metoda infekcji nie jest znana, jednak biorąc pod uwagę ustalone wcześniej powiązania pomiędzy "SPE" i Flamem / Gaussem, możemy uznać za prawdopodobne, że moduł "icsvnt32.ocx" zostaje załadowany i zainstalowany na uprzednio zainfekowanym systemie. Szkodnik jest dostarczany z jednego z serwerów kontroli Flame'a / Gaussa i uruchamiany na życzenie operatora C&C. Możliwa jest również sytuacja, w której "SPE" jest częścią jakiegoś głównego droppera Flame'a (który nie został do tej pory wykryty) lub nieznanym, zaszyfrowanym ładunkiem, który był dystrybuowany przez Gaussa na nośnikach USB (zobacz artykuły [2] i [7]).

Po całkowitym zainfekowaniu systemu, "SPE" rozpoczyna komunikację z serwerem C&C i wysyła do niego zgromadzone informacje. Na tym etapie zebrane dane są prawdopodobnie analizowane przez operatorów. Jeżeli zainfekowany system ofiary nadaje się do wdrożenia "modułu USB", a sama ofiara jest dość interesująca, "moduł USB" ("icsvntu32.ocx") jest instalowany wraz z plikiem "petsec.sys". Na każdym kolejnym etapie oba moduły (moduł główny i moduł infekcji USB) działają niezależnie od siebie. Moduł główny jest odpowiedzialny za wysyłanie danych (z uwzględnieniem informacji zgromadzonych przez "moduł USB") na serwer C&C i wykonywanie rozkazów zwrotnych, natomiast "moduł USB" infekuje dyski wymienne i kradnie zapisane na nich informacje.

Należy podkreślić fakt, iż "moduł USB" nie zawsze jest instalowany. Dla przykładu, jeżeli aktywna jest infekcja wywołana przez Gaussa, a w systemie obecny jest również "SPE", operacje na dyskach USB są wykonywane przez odpowiedni moduł Gaussa.

Informacje o wersjach "SPE"

Jak już wspomnieliśmy wcześniej, wykryliśmy w sumie sześć różnych modyfikacji miniFlame'a, które występują w dwóch grupach wersji – 4.x i 5.x.

"Icsvnt32.ocx" (główny moduł)

"Icsvntu32.ocx" (moduł USB)

We wszystkich wersjach z grupy 4.x twórcy użyli tego samego pliku "informacji o wersji".

Length Of Struc: 0378h
Length Of Value: 0034h
Type Of Struc:   0000h
Info:            VS_VERSION_INFO
Signature:       FEEF04BDh
Struc Version:   1.0
File Version:    1.0.0.1
Product Version: 1.0.0.1
File Flags Mask: 0.63
File Flags:
File OS:         NT (WINDOWS32)
File Type:       DLL
Language/Code Page: 3081/1200
CompanyName:        Microsoft Corporation
FileDescription:    icsvnt32
FileVersion:        1, 0, 0, 1
InternalName:       icsvnt32 (lub icsvntu32 dla modułu "U")
LegalCopyright:     Copyright (C) 2010
LegalTrademarks:
OriginalFilename:   icsvnt32.ocx  (lub icsvntu32 dla modułu "U")
PrivateBuild:
ProductName:        Microsoft Corporation icsvnt32  (lub icsvntu32 dla modułu "U")
ProductVersion:     1, 0, 0, 1
SpecialBuild:
Child Type:         VarFileInfo
Translation:        3081/1200

Najbardziej godnym uwagi szczegółem są informacje o języku skonfigurowanym w systemie, na którym modyfikowano zawartość pliku "informacji o wersji". Skonfigurowana strona kodowa to 3081, co odpowiada ENG_AUS (Angielski (Australia)):

Żaden ze znanych nam modułów Flame'a lub Gaussa nie zawierał informacji o ENG_AUS. Moduły zazwyczaj używały typu kodowania ENGLISH_US lub NEUTRAL. Jednocześnie wersja 5.00 (która jest najnowszą znaną wersją "SPE") używa nowego pliku "informacji o wersji", który wykorzystuje stronę kodowania 1033, co odpowiada ENGLISH_US.

Length Of Struc: 0454h
Length Of Value: 0034h
Type Of Struc:   0000h
Info:            VS_VERSION_INFO
Signature:        FEEF04BDh
Struc Version:   1.0
File Version:    2001.12.4414.320
Product Version: 3.0.0.4414
File Flags Mask: 0.63
File Flags:      
File OS:         WINDOWS32
File Type:       DLL
File SubType:    UNKNOWN
Language/Code Page:  1033/1200
CompanyName:        Microsoft Coporation
FileDescription:    
FileVersion:        2001.12.4414.320
InternalName:       ICSVNT32.DLL
LegalCopyright:     Copyright (C) Microsoft Corp. 1995-1999
LegalTrademarks:    Microsoft(R) is a registered trademark of Microsoft 
Corporation. Windows(TM) is a trademark of Microsoft Corporation
OriginalFilename:   
PrivateBuild:       
ProductName:        COM Services
ProductVersion:     03.00.00.4414
SpecialBuild:  
Child Type:          VarFileInfo
Translation:         1033/1200

Szczególnie interesującym przypadkiem jest wersja 4.20. W wersji tej, podczas procesu kompilowania, autor przez przypadek zawarł ścieżkę dostępu i nazwę projektu jako informacje debugowania CODEVIEW:

 

Wartość 4D629B52 odpowiada znacznikowi czasowemu, który powstał dla momentu, kiedy miało miejsce łączenie plików wykonywalnych, tj. 21/02/2011 17:05:22.

Pełna ścieżka do bazy danych debugowania projektu:

C:\projects\e\SP4.2\general_vob\sp\Release\icsvnt32.pdb

Widać wyraźnie, że gałęzią projektu jest "e", a nazwa projektu i wersja to "SP4.2". Znana jest nazwa pliku wykonywalnego "icsvnt32" i była ona obecna w różnych wersjach szkodnika. Znaczenie frazy "general_vob" pozostaje dla nas tajemnicą.

Statystyki infekcji (dane KSN)

Jak już wcześniej wspomnieliśmy, liczba zidentyfikowanych infekcji "SPE" jest nieduża i bliżej jej do liczby infekcji wywołanych przez Duqu niż Flame'a / Gaussa. Według danych otrzymanych z Kaspersky Security Network, pod koniec września 2012 r. z zainfekowanych maszyn otrzymaliśmy 15 raportów. Wszystkie komputery były zlokalizowane w Zachodniej Azji, głównie w Libanie.

Wierzymy, że większość infekcji wywołanych przez "SPE" w Libanie jest bezpośrednio skojarzona z niedawnymi infekcjami wywołanymi w tym kraju przez Gaussa. Aby udowodnić tę teorię, połączyliśmy raporty infekcji głównego modułu "SPE", "modułu USB" oraz modułów Flame'a i Gaussa.

W rezultacie widać, że tylko dwie, spośród dziesięciu ofiar Gaussa i SPE, posiadały zainstalowany "moduł USB". Wskazuje to na prawdopodobne użycie modułu "dskapi.ocx" Gaussa, gdyż implementuje on niemalże tę samą funkcjonalność, co "moduł USB" skojarzony z "SPE".

Statystyki leja

Podczas naszych badań udało się nam się zassać do leja kilka domen C&C Flame'a i miniFlame'a. Statystyki poniżej sporządzone zostały dla miniFlame'a. Od 28 maja 2012 r. do 30 września 2012 r. naliczyliśmy blisko 14 000 połączeń, pochodzących z około 90 różnych adresów IP:

Rozkład adresów IP ofiar infekcji:

Adresy IP wyśledzone w Stanach Zjednoczonych pochodzą z połączeń VPN. Podobnie, adresy IP pochodzące z Litwy przynależą do dostawcy usług internetowych, który zapewnia satelitarne połączenia internetowe na terenie Libanu. Najbardziej zagadkowe wydają się być adresy IP we Francji – niektóre zdają się pochodzić od proxy lub VPN - ale inne nie są już tak oczywiste. Dla przykładu, jeden z adresów IP ofiary we Francji należy do Uniwersytetu Francoisa Rabelaisa w Tours:

Inne adresy IP we Francji należą do użytkowników internetu mobilnego lub przydzielone zostały darmowym usługom internetowym. Ogólnie rzecz biorąc, wygląda na to, że głównymi lokalizacjami ofiar są Liban i Iran. Rozkład połączeń w tygodniu wygląda następująco:

Z powyższego obrazu wynika, że ofiary były najmniej aktywne w czwartki i w piątki. Poniżej prezentujemy zestawienie wersji, które łączyły się z naszym lejem:

Podczas łączenia się z lejem, miniFlame zgłasza się jako "SP vx.yz", a nie "SPE". Należy również zaznaczyć, że wersja 4.10 najprawdopodobniej nie występuje już "na wolności".

"Icsvnt32.ocx" (główny moduł)

Jako punktu odniesienia użyjemy wersji o numerze 4.50.

Nazwy plików i ścieżki dostępu

Plik jest biblioteką DLL Windows PE z 19 funkcjami eksportu, skompilowaną przy pomocy Microsoft Visual Studio 6.0.
Funkcje eksportu:

Moduł tworzy zdarzenia:

Moduł zapisuje zaszyfrowane pliki dziennika i nadaje im nazwy: "%allusersprofile%\mstlis.log", "%allusersprofile%\datFE2B.da1", "%temp%\daa59.tmp" (tylko w wersji 5.00). Cała rzeczywista funkcjonalność jest realizowana za pomocą dwóch funkcji: "DllMain" (punkt wejścia) i "RegisterService".

"DllMain"

Procedura punktu wejścia działa w dwóch trybach, w zależności od wybranych parametrów. Jeśli parametr "lpReserved" nie jest równy magicznej liczbie 0x1A33F1AB (jest to prawdą dla loadera Windows), uruchamiany jest "tryb loadera". Jeżeli parametr jest równy magicznej liczbie, uruchamiany jest wątek główny.

DllMain, "tryb loadera"

Moduł sprawdza wersję systemu operacyjnego, na której został uruchomiony i dobiera parametry do dalszego działania:

Dla systemów Windows NT 4.0 i nowszych:

Dla systemów Windows 9x:

Moduł występuje w charakterze proxy dla wybranego pliku DLL. Ładuje oryginalną bibliotekę i rozwiązuje nazwy funkcji eksportu, które zostaną zastąpione. Następnie uruchamia wątek loadera i wykonuje powrót z DllMain. W przypadku wystąpienia błędu, moduł czyści rejestr poprzez przywrócenie oryginalnych wartości i powstrzymuje się przed dalszym uruchamianiem.

Wątek loadera

Na początku moduł sprawdza, czy jest uruchomiony w nazwie procesu docelowego (jeśli taki został określony) przez użytkownika o docelowej nazwie. Jeżeli nazwy procesu lub użytkownika nie zgadzają się, wątek jest zamykany. Następnie moduł rozpoczyna wątek monitora rejestru i, jeżeli operacja powiodła się, ładuje swój własny moduł używając własnych procedur manipulacji formatem PE. Następnie przy pomocy magicznej liczby 0x1A33F1AB wykonuje funkcję "DllMain" z załadowanej kopii, co pozwala mu na efektywne uruchomienie się w "trybie głównym".

Wątek monitora rejestru

Moduł otwiera docelowy klucz rejestru i oczekuje na jego modyfikację przy pomocy funkcji API: "RegNotifyChangeKeyValue". Jeżeli domyślna wartość klucza rejestru została zmieniona i nie wskazuje ona na moduł, próbuje on przywrócić zmiany i zwiększa specjalny licznik. Wątek zatrzymuje działanie modułu i czyści rejestr, jeśli napotka więcej niż dwie zmiany w rejestrze lub inny wątek zgłosi zdarzenie "Global\TRStepEvent".

DllMain, "tryb główny"

Po uruchomieniu w "trybie głównym" moduł inicjuje swoje priorytetowe działania, uruchamia komponent interakcji z C&C i wchodzi do pętli głównej operacji.

Jedynie w wersji 5.00: moduł ładuje opcjonalną bibliotekę "%windir%\system32\msfrmt32.dll" i wywołuje jej funkcje eksportu "DllStartServer" i "DllStopServer" odpowiednio przed i po pętli głównej. W procedurze samozniszczenia moduł usuwa ten plik. Cel biblioteki "msfrmt32.dll" pozostaje nieznany. Szczegółowa analiza nie miała miejsca ze względu na brak odpowiednich próbek.

Moduł nieustannie poszukuje uruchomionych procesów antywirusowych, zwracając szczególną uwagę na pliki wykonywalne: "outpost.exe" i "bdagent.exe". Jeżeli którykolwiek z tych procesów zostanie odnaleziony, moduł kończy pracę.

Następnie moduł sprawdza, czy jego pliki dziennika są na tyle obszerne, aby poddać je wyprowadzeniu na zdalny serwer, i jeżeli jest to prawdą przenosi każdy dziennik do lokalizacji "%allusersprofile%\Wnm.tmp", skąd następnie przesyła treść dzienników do pierwszego dostępnego serwera C&C. Połączenie z serwerem C&C ma miejsce tylko wtedy, gdy moduł najpierw może wywołać stronę "http://www.google.com". Jeżeli strona odpowiada, moduł łączy się z serwerem C&C i pobiera nowe rozkazy.

Informacje o centrum kontroli

Lista serwerów C&C jest stała i składa się z dwóch tablic: pierwsza tablica zawiera nazwy hostów i adresy IP serwerów, natomiast druga tablica zawiera adresy URL odpowiadające każdemu serwerowi.

Wersja 4.00, 4.20, 4.30, 4.40

Wersja 4.50

Wersja 5.00

 
Odszyfrowany ciąg znaków z wersją szkodliwego oprogramowania i domenami C&C w próbce miniFlame'a

Domeny używane w wersji 5.00 - poza kilkoma wyjątkami - są takie same, jak domeny używane w kilku znanych wersjach Flame'a [8]. Tak więc, "SPE" i Flame komunikowały się z tymi samymi serwerami C&C i były obsługiwane przez ten sam zestaw oprogramowania, który opisywaliśmy wcześniej, przy okazji szczegółowej analizy serwerów C&C Flame'a. Po stronie serwera połączenia nawiązywane przez miniFlame'a były przetwarzane przez kod protokołu "OldProtocolE", który identyfikował klienta jako "SPE".

Protokół komunikacyjny

Moduł wybiera pierwszy dostępny serwer, a jeżeli połączenie nie powiedzie się, przełącza się do następnego wolnego serwera. Podczas operacji moduł odczytuje i zapisuje swoje wewnętrzne dane konfiguracji w kluczu rejestru:

[HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation] StandardTimeBias

Co ciekawe, ten klucz rejestru jest również znany Flame'owi. Moduł Flame'a, który przeprowadza unikalny atak MitM [6], podczas rozprzestrzeniania się za pośrednictwem sieci lokalnej sprawdza, czy ten klucz "SPE" jest obecny w infekowanym systemie i jeżeli jest, moduł pomija ten system. Tak więc, systemy zainfekowane przez "SPE" są rozpoznawane i unikane przez kod replikacji Flame'a.

Protokół komunikacyjny C&C jest oparty na HTTP: moduł wysyła zarówno żądania, jak i odpowiedzi w ciele zgłoszenia HTTP POST, a serwer może odpowiadać modułowi wysyłanymi rozkazami. Wszystkie dane wysyłane na serwer C&C umieszczane są w zawartości zgłoszenia POST. Pakiet rozpoczyna się 10-bajtowym kluczem XOR i ciągiem znaków, zaszyfrowanym przy pomocy tego klucza. Wygląda on jak ciąg znaków żądania HTTP i zawiera podstawowe informacje dotyczące zgłoszenia:

"U=unikalny_identyfikator_ofiary&K=1&A=1 lub 3&F=wewnętrzny_numer_pliku&S=rozmiar_aktualnego_zgłoszenia"

Po ciągu znaków żądania występuje druga część żądania, która jest zaszyfrowana przy pomocy algorytmu Twofish. Rozmiar zaszyfrowanej części jest definiowany poprzez wartość "S=" w pierwszej części pakietu. Druga część pakietu zawiera więcej informacji o komputerze i o samym żądaniu:

UNIQUE_NUMBER=unikalny_identyfikator_ofiary
PASSWORD=LifeStyle2
TOOL_B=SP_numer_wersji
COM_B=H
LI=0
VERSION_INFO=zaszyfrowana_wersja_Windows
SERVICE_PACK=numer_poprawki_Service_Pack
IP=adres_IP_ofiary
MAC=adres_MAC_hosta
COMPUTER_NAME=nazwa_komputera_w_systemie_Windows
CMD_ATTEMPTS=liczba_otrzymanych_rozkazów
SUC_CMD_ATTEMPTS=liczba_rozkazów_wykonanych_pomyślnie
SEC_COUNT=GetTickCount()/1000
LOGGED_ON=1/0(jeśli uruchomiony jest proces explorer.exe)
COMP_ID=wartość [HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current\Software\Fonts] PixelShader
ACTION=liczba
FILE_NAME=wewnętrzny_numer_pliku

Zwróćmy uwagę na wartość parametru PASSWORD. Tą wartością jest "LifeStyle2" - to samo hasło używane jest podczas komunikacji z serwerami C&C wszystkich znanych wersji Flame'a.

Po drugiej części żądania może następować opcjonalna część trzecia, która zawiera jeszcze więcej danych. Może to być plik dziennika, plik z komputera ofiary lub dziennik poleceń otrzymany z serwera C&C. Trzecia część jest szyfrowana kolejną warstwą algorytmu Twofish, wykorzystującą ten sam klucz. Format odpowiedzi serwera jest znacznie prostszy: jest to bufor zawierający rozkazy i ich parametry, zaszyfrowane przy pomocy jednowarstwowego algorytmu Twofish, używającego tego samego klucza. Każda linia w buforze reprezentuje polecenie:

<!-- NAZWA_ROZKAZU CONTINUE_ON_ERROR(0/1) parametry … serwer_do_wysłania_wyników port_do_wysłania_wyników --> \n

Dostępne rozkazy:

Po wykonaniu wszystkich poleceń wydanych przez serwer, bot wysyła do serwera nowe zgłoszenie, które zawiera dziennik wykonanych rozkazów. Jeśli którekolwiek z poleceń wymagają od bota wysyłania danych na serwer (np. SONIA), są one wysyłane w oddzielnych żądaniach HTTP poprzedzających zgłoszenie dziennika. Żądania te mogą zostać przekierowane do innych serwerów C&C, jeżeli zostało to zaznaczone w parametrach rozkazów.

BARBARA

Kiedy moduł otrzyma rozkaz "BARBARA", najpierw pobiera czas ostatniej aktywności użytkownika i kontynuuje operację, tylko jeśli komputer nie jest w stanie spoczynku. Następnie wykonuje zrzut ekranu całego pulpitu, zapisuje go w formacie BMP, kompresuje z wykorzystaniem algorytmu PPMd (zmodyfikowany wariant "I") i w osobnym zgłoszeniu wysyła zrzut ekranu na swój serwer C&C. Warto przypomnieć, że jeden z modułów szkodliwego oprogramowania Flame do kompresowania zrzutów ekranu używał dokładnie tego samego algorytmu (PPMd). Procedura obsługi polecenia "BARBARA" może zostać uruchomiona w różnych trybach i może zbierać zrzuty ekranu, tylko jeśli okno na pierwszym planie należy do procesu z ustalonej listy; jednakże ta funkcja jest wyłączona.

 
Przykład testowego zrzutu ekranu wykonanego przez moduł po otrzymaniu rozkazu
"BARBARA" na systemie z uruchomionym Microsoft Visio

Po wykonaniu wszystkich poleceń wydanych przez serwer, bot wysyła do serwera nowe zgłoszenie, które zawiera dziennik wykonanych rozkazów. Jeśli którekolwiek z poleceń wymagają od bota wysyłania danych na serwer (np. SONIA), są one wysyłane w oddzielnych żądaniach HTTP poprzedzających zgłoszenie dziennika. Żądania te mogą zostać przekierowane do innych serwerów C&C, jeżeli zostało to zaznaczone w parametrach rozkazów.

Funkcja eksportu "RegisterService"

Ta funkcja może zostać wywołana przez zewnętrzny moduł, np. składnik loadera Gaussa. Jest to procedura instalacyjna: kopiuje moduł do katalogu systemowego i modyfikuje rejestr, tak aby skopiowany moduł był uruchamiany przy starcie systemu.

Moduł sprawdza, czy został uruchomiony na systemie Windows 2000, czy nowszej wersji systemu NT (XP, Vista, 7) i wykonuje powrót, jeśli nie jest to prawdą. Moduł sprawdza również, czy w systemie uruchomione są procesy "outpost.exe" i "bdagent.exe". Jeżeli któryś z tych procesów jest obecny, moduł czyści rejestr i kończy swoje działanie. Następnie moduł kopiuje plik "%windir%\system32\icsvnt32a.ocx" do tymczasowego katalogu z prefiksem "%allusersprofile%\gfw". Później przenosi ten plik z lokalizacji tymczasowej do właściwej lokalizacji "%windir%\system32\icsvnt32.ocx". Pobiera również czas utworzenia pliku "%windir%\system32\kernel32.dll" i ustawia identyczną wartość jako czas utworzenia swojego własnego pliku. Oryginalny plik "%windir%\system32\icsvnt32a.ocx" zostaje przeznaczony do usunięcia przy pierwszym powtórnym uruchomieniu komputera.

Jeżeli plik "icsvnt32.ocx" zostanie zainstalowany bez żadnych błędów, moduł zmienia domyślną wartość docelowego klucza rejestru na "%windir%\system32\icsvnt32.ocx". Poprzez podmianę jednego systemowego obiektu COM, moduł rejestruje się w systemie i dzięki temu jest ładowany przez większość procesów systemowych.

"Icsvntu32.ocx" (infekcja USB)

Ten moduł jest oparty na tym samym kodzie źródłowym co "icsvnt32.ocx" i posiada wiele identycznych funkcji. Plik zawiera kod do interpretacji rozkazów z serwera C&C, ale jest on błędny. Powinien łączyć się z serwerem kontroli, lecz generuje przekierowanie, które prowadzi do zapisu danych w pliku dziennika.

Moduł jest biblioteką DLL Windows PE z 19 funkcjami eksportu, skompilowanymi przy pomocy Microsoft Visual Studio 6.0.
Funkcje eksportu:

Moduł tworzy zdarzenia:

Moduł tworzy zaszyfrowane pliki dziennika o nazwach: "%allusersprofile%\mstlis.log", "%allusersprofile%\datFE2B.da1", "%allusersprofile%\datFE2A.tmp".

"DllMain"

Procedura punktu wejścia pracuje w dwóch różnych trybach, w zależności od parametrów. Jeżeli parametr "lpReserved" nie jest równy magicznej liczbie 0x1A33F1AB (co jest prawdą dla loadera Windows), moduł zaczyna działać w "trybie loadera". Jeżeli parametr jest równy magicznej liczbie, rozpoczynany jest wątek główny.

DllMain, "tryb loadera"

Moduł sprawdza wersję systemu operacyjnego, na której został uruchomiony i dobiera parametry do dalszego działania:

Dla systemów Windows NT 4.0 i nowszych oraz dla systemów Windows 9x:

Parametry dla wersji systemu NT i 9x są takie same, ale różne są funkcje, które inicjują wartości tych parametrów.

Moduł zdaje się operować jako proxy dla wybranego pliku DLL. Ładuje oryginalną bibliotekę i rozwiązuje nazwy jej funkcji eksportu, które zostaną zastąpione. Następnie moduł uruchamia wątek loadera i wykonuje powrót z "DllMain". W przypadku wystąpienia błędu, moduł wykonuje czyszczenie rejestru poprzez przywrócenie oryginalnych wartości i powstrzymuje się przed kolejnym uruchomieniem.

Wątek loadera

Na początku moduł sprawdza, czy jest uruchomiony w nazwie procesu docelowego (jeśli taki został określony) przez użytkownika o docelowej nazwie. Jeżeli nazwy procesu lub użytkownika nie zgadzają się, wątek jest zamykany. Następnie moduł rozpoczyna wątek monitora rejestru i, jeżeli operacja powiodła się, ładuje swój własny moduł używając własnych procedur manipulacji formatem PE. Następnie, pomocy magicznej liczby 0x1A33F1AB, wykonuje funkcję "DllMain" załadowanej kopii, co pozwala mu na efektywne uruchomienie się w "trybie głównym".

Wątek monitora rejestru

Moduł otwiera docelowy klucz rejestru i oczekuje na jego modyfikację przy pomocy funkcji API: "RegNotifyChangeKeyValue". Jeżeli domyślna wartość klucza rejestru została zmieniona i nie wskazuje ona na moduł, próbuje on przywrócić zmiany i zwiększa specjalny licznik. Wątek zatrzymuje działanie modułu i czyści rejestr, jeśli napotka więcej niż dwie zmiany w rejestrze lub inny wątek zgłosi zdarzenie "Global\TRStepEventU".

DllMain, "tryb główny"

Po uruchomieniu w "trybie głównym", moduł zaczyna realizować swoje podstawowe zadania i zamienia komponent interakcji z C&C (na podobny do składnika w "icsvnt32.ocx"). Tworzy on również pulpit o nazwie "Default3" i przypisuje swój główny wątek do tego pulpitu. Następnie, moduł wchodzi do pętli głównej operacji. Moduł nieustannie poszukuje uruchomionych procesów antywirusowych, zwracając szczególną uwagę na pliki wykonywalne: "outpost.exe" i "bdagent.exe". Jeżeli którykolwiek z tych procesów zostanie odnaleziony, moduł kończy pracę.

Pętla głównej operacji jest zmodyfikowaną pętlą interakcji z C&C pobraną z "icsvnt32.ocx", która zamiast połączenia z serwerem rozpoczyna procedury infekcji dysku. Podczas operacji, moduł odczytuje i zapisuje swoje wewnętrzne dane konfiguracji w wartości rejestru:

[HKCU\Console]
StandardTimeBiasU

Procedura infekcji napędu USB

Moduł wylicza wszystkie dostępne napędy USB. Następnie infekowane są wszystkie urządzenia USB o systemie plików FAT, FAT32 i NTFS. Najpierw moduł pobiera informacje o dysku i zapisuje je w raporcie "%allusersprofile%\mstlis.log". Następnie, próbuje wyleczyć dysk z potencjalnej infekcji dokonanej przez starszy wariant szkodnika usuwając następujące pliki:

System32.dat
.Catroot.tmp

Poszukuje również katalogów, w których nazwach występuje ".Backup0D" – ".Backup0M" i dla każdego takiego usuwa pliki "target.lnk" i "desktop.ini" oraz sam folder. Te katalogi są tworzone podczas infekcji przeprowadzanych przez "moduł USB" Gaussa.

Jeżeli urządzenie w swoim katalogu głównym posiada plik ".thumbs.db", moduł odczytuje zawartość tego pliku i zapisuje ją w pliku dziennika "%allusersprofile%\datFE2A.tmp". Wpis do dziennika jest poprzedzany ciągiem znaków "USB_RESULT" i aktualną datą oraz czasem. Jeśli plik dziennika jest uważany za wystarczająco duży do wyprowadzenia go na zewnątrz, zawartość ".thumbs.db" jest zapisywana do kolejnego pliku dziennika: "%allusersprofile%\datFE2B.da1". Następnie moduł infekuje urządzenie. Tworzy nowy plik o nazwie ".thumbs.db" w katalogu głównym urządzenia. Plik zawiera magiczną liczbę 0x0EB397F2B i wartość TTL równą 10. Licznik TTL jest zmniejszany przez ładunek uruchamiany z dysku USB, a ładunek czyści dysk, gdy licznik osiągnie wartość zero.

Format pliku ".thumbs.db" jest identyczny, jak format stosowany przez moduł Gaussa "dskapi.ocx".

Moduł odszyfrowuje plik "%allusersprofile%\petsec.sys" używając ustalonego klucza Twofish i zapisuje go w katalogu głównym dysku pod nazwą "System32.dat". Plik jest biblioteką PE DLL i powinien być ładowany z zainfekowanego dysku przez exploit LNK. Następnie, moduł tworzy katalogi ".Backup0D" – ".Backup0M". W każdym z tych katalogów tworzone są pliki "target.lnk" i "desktop.ini". Pierwszy plik zawiera exploit LNK, który ładuje plik "System32.dat", a drugi z plików konwertuje katalog do formatu pliku skrzyżowanego.

Funkcja eksportu "RegisterService"

Ta funkcja może zostać wywołana przez zewnętrzny moduł, np. składnik loadera Gaussa. Jest to procedura instalacyjna: kopiuje moduł do katalogu systemowego i modyfikuje rejestr, tak aby skopiowany moduł był uruchamiany przy starcie systemu. Moduł sprawdza, czy został uruchomiony na systemie Windows 2000, czy nowszej wersji systemu NT (XP, Vista, 7) i wykonuje powrót, jeśli nie jest to prawdą. Moduł sprawdza również, czy w systemie uruchomione są procesy "outpost.exe", "bdagent.exe" i "antivirus.exe". Jeżeli któryś z tych procesów jest obecny, moduł czyści rejestr i kończy swoje działanie.

Następnie moduł kopiuje plik "%allusersprofile%\icsvntu32a.ocx" do tymczasowego katalogu z prefiksem "%allusersprofile%\gfw". Później przenosi ten plik z lokalizacji tymczasowej do właściwej lokalizacji "%allusersprofile%\icsvntu32.ocx". Pobiera również czas utworzenia pliku "%windir%\system32\kernel32.dll" i ustawia identyczną wartość jako czas utworzenia swojego własnego pliku. Oryginalny plik "%allusersprofile%\icsvntu32a.ocx" zostaje przeznaczony do usunięcia przy pierwszym powtórnym uruchomieniu komputera. Jeżeli plik "icsvntu32.ocx" zostanie zainstalowany bez żadnych błędów, moduł zmienia domyślną wartość docelowego klucza rejestru na "%allusersprofile%\icsvntu32a.ocx". Poprzez podmianę jednego systemowego obiektu COM, moduł rejestruje się w systemie i dzięki temu jest ładowany przez większość procesów systemowych.

".CatRoot.tmp" / "System32.dat"

Byliśmy w stanie odszukać kopię pliku "petsec.sys", o którym mowa w wersji 4.00 "SPE". Lokalizacja pliku na zainfekowanym dysku USB: "\.CatRoot.tmp", "\System32.dat".
Właściwości pliku:

Plik tworzy mutex "Isvp4003ltrEvent" i jest biblioteką DLL Windows PE, nie zawierającą funkcji eksportu i skompilowaną przy pomocy Microsoft Visual Studio 6.0. Bieżąca funkcjonalność jest zaimplementowana w funkcji "DllMain" (punkt wejścia). Funkcjonalność modułu jest prawie identyczna jak funkcjonalność plików "System32.dat" / "System32.bin" zapisywanych przez moduł Gaussa "dskapi.ocx": zbiera informacje o systemie, na którym został uruchomiony i zapisuje je do pliku na zainfekowanym dysku USB.

Powyższy wariant odpowiada wersji 4.00 modułu "icsvntu32.ocx" i prawdopodobnie posiada nazwę ".CatRoot.tmp". Nowsza wersja "icsvntu32.ocx" infekuje dyski USB plikiem o nazwie "System32.dat", jednakże nie dysponujemy próbkami tego szkodliwego ładunku.

"DllMain"

Moduł sprawdza, czy jego nazwa zawiera kompletną oryginalną nazwę pliku, ".CatRoot.tmp" (wersja 4.00). Ponieważ moduł zawiesza się, gdy jego nazwa jest inna, nowsze modyfikacje modułu powinny stosować inną nazwę - "System32.dat". Jeżeli nazwa pliku się zgadza, moduł kopiuje się do lokalizacji "%TEMP%\%cCatRoot.tmp", gdzie "%c" jest nazwą dysku, z którego uruchomiony został moduł. Dla przykładu, jeżeli moduł wystartował z dysku "F:", lokalizacja będzie wyglądała następująco: "%TEMP%\FCatRoot.tmp". Następnie moduł ładuje swoją nową kopię i wykonuje powrót.

Jeśli nazwa pliku zawiera jego oryginalną nazwę bez pierwszego symbolu (np. "CatRoot.tmp" bez kropki), moduł zakłada, że został załadowany z kopii lokalnej i przystępuje do wykonywania swojej głównej procedury. Moduł oznacza system jako zainfekowany zapisując następujący klucz rejestru:

[HKCU\Control Panel\Desktop]
WindowBuildVal = losowa wartość

Następnie, odczytuje plik ".thumbs.db" z katalogu głównego zainfekowanego dysku USB. 32-bitowa wartość całkowita na offsecie 4 tego pliku zawiera licznik życia TTL (ang. Time To Live) modułu. Licznik jest zmniejszany przy każdym załadowaniu modułu, a gdy jego wartość dojdzie do zera, moduł wykonuje procedurę samousuwania. Jeśli wartość TTL jest większa niż zero, moduł realizuje procedurę zbierania danych.

Procedura gromadzenia danych

Moduł gromadzi kilka typów danych i zapisuje je na końcu pliku ".thumbs.db" w głównym katalogu zainfekowanego urządzenia USB. Plik jest szyfrowany przy pomocy algorytmu XOR, a jego format jest identyczny, jak format wykorzystywany przez moduł Gaussa "dskapi.ocx". Moduł gromadzi następujące informacje:

• Nazwa komputera;
• Wersja systemu Windows;
• Typ platformy;
• Lista kart sieciowych;
• Zawartość tablicy ARP;
• Lista załadowanych modułów i procesów;
• Lista plików w głównych katalogach dysków lokalnych i sieciowych, po 200 nazw dla każdego dysku;
• Lista plików w katalogach, po 200 nazw dla każdego katalogu:
  • "%TEMP%\*"
  • "%userprofile%\Desktop\*"
  • "%windir%\Prefetch\*"
  • "%programfiles%\*"
• Lista widzianych serwerów sieciowych.

Procedura samousuwania

Moduł usuwa plik ".CatRoot.tmp" z głównego katalogu zainfekowanego napędu. Następnie, katalog główny jest przeszukiwany pod kątem obecności podkatalogów o nazwach ".Backup0D" – ".Backup0M", a dla każdego z tych podkatalogów moduł:

• usuwa pliki "desktop.ini" i "target.lnk";
• usuwa sam folder.

Plik ".thumbs.db" nie jest usuwany podczas wykonywania procedury samodzielnej dezinstalacji.

Wnioski

Podczas analizy kodu centrum kontroli Flame'a, zidentyfikowaliśmy cztery odmiany szkodliwego oprogramowania znane serwerowi C&C: "SP", "SPE", "FL" i "IP". Pod nazwą kodową "FL" kryje się Flame. Szkodnik znany jako "SPE" został opisany w niniejszym artykule.

Opierając się na przeprowadzonej analizie, byliśmy w stanie połączyć ze sobą kilka cech charakterystycznych szkodnika "SPE", którego nazywamy również "miniFlame" lub "John" (w ten sposób nazwano go w konfiguracji Gaussa):

• Szkodnik występuje wyjątkowo rzadko. Prawdopodobnie był wdrażany na komputerach ofiar mających największe znaczenie dla napastników.
• W przeciwieństwie do Gaussa, "SPE" implementuje w pełni funkcjonalnego backdoora typu klient / serwer, który pozwala operatorom na uzyskanie bezpośredniego dostępu do zainfekowanego systemu.
• Kod C&C Flame'a, który analizowaliśmy, nie zawierał specyficznych modułów do kontroli klientów "SPE"; możemy założyć, że istnieją lub istniały specjalne serwery dedykowane "SPE".
• Rozwój projektu "SPE" postępował równolegle z pracami nad Flamem i Gaussem w okresie 2010 - 2011 r.
• Zarówno Flame, jak i Gauss, mogą używać miniFlame'a / SPE jako własnego modułu.
• Najnowszym wariantem "SPE" jest wersja 5.00; najstarszym - wersja 4.00.
• Dokładny wektor infekcji "SPE" pozostaje nieznany; wierzymy, że to szkodliwe oprogramowanie jest wdrażane z serwerów centrum kontroli podczas masowych infekcji Flame'a lub Gaussa.
• Wersja szkodnika opatrzona numerem 4.20 zawiera ścieżkę debugowania w znaczniku binarnym, która wskazuje na lokalizację: "C:\projects\e\SP4.2\general_vob\sp\Release\icsvnt32.pdb". Pokazuje to, że twórcy nazwali tego szkodnika "SP4.2", mimo że używa on klienta typu "SPE". Jest bardzo możliwe, że za nazwą "SP" stoją wcześniejsze wersje miniFlame'a / SPE – 1.00 do 3.x.
• "SPE" umacnia teorię istnienia ścisłej współpracy grup tworzących Flame'a i Gaussa. miniFlame reprezentuje wspólny moduł, wykorzystywany przez oba te projekty.
• Wszystkie znane wersje "SPE" opatrzone numerem 4.xx zawierają sekcję "informacji o wersji", która odnosi się do strony kodowania 3081: ENG_AUS, Angielski (Australia).

Projekty Flame i Gauss były masowymi operacjami cyberszpiegowskimi, infekującymi tysiące użytkowników. SPE / miniFlame jest wysoce precyzyjnym narzędziem szpiegowskim. Liczba ofiar tego szkodliwego oprogramowania jest porównywalna do ofiar infekcji Duqu. Możemy założyć, że miniFlame był częścią operacji Flame i Gauss, które odbyły się w kilku fazach. Pierwsza faza: zainfekowanie jak największej liczby potencjalnie interesujących ofiar. Druga faza: zbieranie danych od ofiar, pozwalające atakującemu określić profile ofiar i znaleźć najciekawsze cele. Finalna faza: dla "wybranych" celów zastosowanie wyspecjalizowanego narzędzia szpiegowskiego, takiego jak SPE / miniFlame, do prowadzenia nadzoru / monitoringu.

Wewnątrz kodu C&C Flame'a istnieje odniesienie do dwóch dotąd nieznanych części szkodliwego oprogramowania: "SP" i "IP". "SP" to najprawdopodobniej starszy wariant szkodnika opisanego w tym artykule. "IP" to prawdopodobnie odrębna część szkodliwego oprogramowania, która do tej pory pozostaje nieznana.

Analizując Flame'a, Gaussa i miniFlame'a najprawdopodobniej odkryliśmy czubek góry lodowej masowych operacji cyberszpiegowskich, mających miejsce na Bliskim Wschodzie. Ich prawdziwy cel pozostaje niejasny, a tożsamość ofiar i napastników pozostaje nieznana.

Referencje

[1] Flame: Pytania i odpowiedzi
[2] Gauss: nietypowa dystrybucja
[3] Pełna analiza serwerów centrum kontroli Flame'a
[4] Powrót do Stuxneta: brakujące ogniwo
[5] Stuxnet/Duqu: ewolucja sterowników
[6] Flame: replikacja przez serwer proxy utworzony w wyniku ataku MITM
[7] Zagadka zaszyfrowanej zawartości Gaussa
[8] Dach płonie: walka z serwerami kontroli Flame'a