miniFlame zwany SPE: "Elvis i jego przyjaciele"


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臋:

Nazwa Incydenty (statystyki Kaspersky Lab) Incydenty (szacunkowo)
Stuxnet wi臋cej ni偶 100 000 wi臋cej ni偶 300 000
Gauss oko艂o 2500 oko艂o 10 000
Flame ("FL") oko艂o 700 oko艂o 5000 - 6000
Duqu oko艂o 20 oko艂o 50 - 60
miniFlame ("SPE") oko艂o 10 - 20 oko艂o 50 - 60

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":

Fragment konfiguracji Flame'a datowany na dzie艅 21.07.2010 r.
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.

Fragment konfiguracji Flame'a datowany na dzie艅 01.08.2010 r.
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.

Fragment pliku "watchxb.sys"
Files.10 : %windir%\system32\mspbee32.ocx
Files.9 : %windir%\system32\mspbee32.dll
Files.8 : %windir%\system32\comspol32.ocx
Files.7 : %windir%\system32\comspol32.dll
Files.6 : %windir%\system32\commgr32.ocx
Files.5 : %windir%\system32\commgr32.dll
Files.4 : %windir%\system32\icsvnt32.ocx
Files.3 : %windir%\system32\icsvnt32.dll

Files.2 : %windir%\system32\mssvc32.ocx
Files.1 : %windir%\system32\mssvc32.dll
RegKeys.5 : HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\StandardSize
RegKeys.4 : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit\LastUsedIdentifier
RegKeys.3 : HKLM\SOFTWARE\Classes\CLSID\{4E14FBA2-2E22-11D1-9964-00C04FBBB345}\InprocServer32\#icsvnt32.ocx
RegKeys.2 : HKLM\SOFTWARE\Classes\CLSID\{4E14FBA2-2E22-11D1-9964-00C04FBBB345}\InprocServer32\#icsvnt32.dll

RegKeys.1 : HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32\wave9#%commonprogramfiles%\Microsoft Shared\MSAudio\wavesup3.drv

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".

Przyk艂adowy plik konfiguracyjny Gaussa
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艂)

Wersja Data kompilacji MD5 Rozmiar
4.00 10.10.2010 6F5ACDC848508C33F15634B1A068B16D 75264
4.20 21.02.2011 11C845B2C254C4170E9E49177F5053BB 89680
4.30 09.03.2011 16C986E14D34C7881E16186384DAB968 76288
4.40 11.04.2011 3091B15D27EEEE830FF85C50D50B3A05 97280
4.50 26.07.2011 B3E630714BF2526D3AA70370D2AC54B7 96768
5.00 01.09.2011 256469662C493731D4CEB003FC4783B1 104448

"Icsvntu32.ocx" (modu艂 USB)

Wersja Data kompilacji MD5 Rozmiar
4.30 09.03.2011 523C6D9229B5656942B2CADEA3F0824C 108544
4.40 11.04.2011 E4EA1110E5915B7B66B405979E586887 113152
4.50 20.07.2011 A4C2DD6F3998A7625196DC79B1954150 112128

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.

Kraj Liczba incydent贸w
Liban 10
Terytorium Palesty艅skie 3
Katar 1
Kuwejt 1

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.

Ofiary "SPE" Wcze艣niejsza infekcja Flamem Wcze艣niejsza infekcja Gaussem Modu艂 USB
Liban#1 Nie Nie Nie
Liban#2 Nie Tak Nie
Liban#3 Nie Tak Tak
Liban#4 Nie Tak Nie
Liban#5 Nie Tak Nie
Terytorium Palesty艅skie#1 Nie Tak Nie
Katar#1 Nie Nie Tak
Liban#6 Tak Tak Nie
Liban#7 Nie Nie Tak
Liban#8 Nie Nie Nie
Liban#9 Tak Tak Nie
Kuwejt#1 Nie Nie Tak
Terytorium Palesty艅skie#2 Nie Tak Nie
Liban#10 Tak Tak Tak
Terytorium Palesty艅skie#3 Tak Tak Nie

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

Nazwy plik贸w Foldery
icsvnt32.ocx %windir%\System32
icsvnt32a.ocx %windir%\System32
icsvntu32.ocx "%allusersprofile%\ (Documents and Settings\All Users)
icsvntu32a.ocx "%allusersprofile%\ (Documents and Settings\All Users)
ICSVNTU32.OCX ProgramData
ICSVNTU32A.OCX ProgramData

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

L.p. Nazwa
1 DllGetClassObject
2 DllCanUnloadNow
3 <brak>
4 DllRegisterServer
5 DllUnregisterServer
6 NotifyLogoffUser
7 NotifyLogonUser
8 ServiceMain
9 LCEControlServer
10 RegisterTheFrigginEventServiceDuringSetup
11 RegisterTheFrigginEventServiceAfterSetup
12 RegisterTheEventServiceDuringSetup
13 RegisterTheEventServiceAfterSetup
14 RestoreMyDocsFolder
15 PerUserInit
16 DllInstall
17 CreateSharedDocuments
18 RegisterService
19 SvchostPushServiceGlobals

Modu艂 tworzy zdarzenia:

Nazwa zdarzenia Komentarz
Global\TRStepEvent wszystkie wersje
Global\EPOAgentEvent opr贸cz wersji 5.00
Global\MICEvent tylko w wersji 5.00
Global\AdvTW32SyncEvent wszystkie wersje
Global\AdvTW32ReadyXXXWfEvent gdzie XXX jest numerem wersji (np. 450)

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:

Nazwa procesu docelowego svchost.exe
Docelowa nazwa u偶ytkownika SYSTEM
Docelowy klucz rejestru HKLM\SOFTWARE\Classes\CLSID\{4E14FBA2-2E22-11D1-9964-00C04FBBB345}\InProcServer32
Nazwa hosta DLL es.dll

Dla system贸w Windows 9x:

Nazwa procesu docelowego explorer.exe
Docelowa nazwa u偶ytkownika brak
Docelowy klucz rejestru HKLM\SOFTWARE\Classes\CLSID\{450D8FBA-AD25-11D0-98A8-0800361B1103}\InProcServer32
Nazwa hosta DLL mydocs.dll

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

Nazwa serwera Adres URL
webupdate.hopto.org /cgi-bin/feed.cgi
webapp.serveftp.com /cgi-bin/feed.cgi
web.autoflash.info /cgi-bin/feed.cgi
web.velocitycache.com /cgi-bin/feed.cgi
webupdate.dyndns.info /cgi-bin/feed.cgi
cache.dyndns.info /cgi-bin/feed.cgi

Wersja 4.50

Nazwa serwera Adres URL
flashcenter.info /cgi-bin/feed.cgi
flashrider.org /cgi-bin/feed.cgi

Wersja 5.00

Nazwa serwera Adres URL
flashupdates.info /cgi-bin/counter.cgi
syncstream.info /cgi-bin/counter.cgi
nvidiasoft.info /cgi-bin/counter.cgi
202.75.58.179 /cgi-bin/counter.cgi
nvidiadrivers.info /cgi-bin/counter.cgi
nvidiastream.info /cgi-bin/counter.cgi
videosync.info /cgi-bin/counter.cgi
rendercodec.info /cgi-bin/counter.cgi
194.192.14.125 /cgi-bin/counter.cgi

 
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:

Nazwa polecenia Opis
FIONA Zapisz na komputerze ofiary plik z serwera C&C
SONIA Prze艣lij na serwer C&C plik z komputera ofiary
EVE Za艂aduj zdefiniowan膮 bibliotek臋 DLL i wywo艂aj bez argument贸w okre艣lon膮 funkcj臋 eksportu
ELVIS Utw贸rz proces o okre艣lonych parametrach i czekaj na jego uruchomienie
DRAKE Usu艅 z rejestru parametr "StandardTimeBias" i zasygnalizuj zdarzenie "Global\TRStepEvent" (procedura samounicestwienia)
CHARLES Zapisz do rejestru now膮 warto艣膰 "StandardTimeBias"
SAM Przejd藕 w tryb u艣pienia na okre艣lony czas
ALEX (wersja 5.00) Zmierz czas bezczynno艣ci systemu i podaj go w milisekundach
BARBARA (wersja 5.00) Zr贸b zrzut ekranu z okna na pierwszym planie, je艣li nale偶y ono do jednego ze wst臋pnie zdefiniowanych proces贸w
TIFFANY (wersja 5.00) Prze艂膮cz si臋 na serwer C&C okre艣lony w parametrach rozkazu

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.

Nazwa procesu Opis
Iexplore.exe Przegl膮darka Internet Explorer
Mozilla.exe Przegl膮darka Mozilla
Outlook.exe MS Outlook
Msimn.exe MS Outlook Express
Winword.exe MS Word
Excel.exe MS Excel
Msmsgs.exe MSN Messenger
Msgplus.exe Rozszerzenie MSN Messenger
Msnmsgr.exe Rozszerzenie MSN Messenger
Msdev.exe Microsoft Developers Studio
Explorer.exe Eksplorator Windows
Cygwin.exe Podobne do Linuxa 艣rodowisko dla systemu Windows, umo偶liwiaj膮ce uruchomienie na systemie Windows oprogramowania dla system贸w POSIX (takich jak Linux, BSD i Unix)
Acrobat.exe Adobe Acrobat
Acrord32.exe Adobe Acrobat Reader
Aim.exe Komunikator internetowy AOL
Aim95.exe Komunikator internetowy AOL
Frontpage.exe Edytor MS FrontPage
Icq.exe Komunikator internetowy ICQ
Icqlite.exe ICQ Lite
Inetinfo.exe Komponent, kt贸ry hostuje metabaz臋 IIS i niesieciowe us艂ugi IIS 6.0
Exceed.exe System zarz膮dzania przedsi臋biorstwem Hummingbird Ltd. / OpenText
telnet.exe Klient Windows Telnet
ftp.exe Klient Windows FTP
Putty.exe Klient SSH / Telnet
Netscape.exe Przegl膮darka Netscape Navigator
Notepad.exe Notatnik Windows
Winproj.exe Projekt Microsoft Office
Powerpnt.exe Microsoft PowerPoint
Visio.exe MS Visio
Ypager.exe Yahoo Messenger
Mstsc.exe Pod艂膮czenie zdalnego pulpitu Microsoft
mmc.exe Konsola zarz膮dzania Microsoft
Paltalk.exe PalTalk Messenger
Onenote.exe Microsoft Office OneNote
Onenotem.exe Szybkie uruchamianie dla Microsoft Office OneNote

 
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:

L.p. Nazwa
1 DllGetClassObject
2 DllCanUnloadNow
3 <brak>
4 DllRegisterServer
5 DllUnregisterServer
6 NotifyLogoffUser
7 NotifyLogonUser
8 ServiceMain
9 LCEControlServer
10 RegisterTheFrigginEventServiceDuringSetup
11 RegisterTheFrigginEventServiceAfterSetup
12 RegisterTheEventServiceDuringSetup
13 RegisterTheEventServiceAfterSetup
14 RestoreMyDocsFolder
15 PerUserInit
16 DllInstall
17 CreateSharedDocuments
18 RegisterService
19 SvchostPushServiceGlobals

Modu艂 tworzy zdarzenia:

Nazwa zdarzenia Komentarz
Global\TRStepEventU wszystkie wersje
Global\EPOAgentEventU wszystkie wersje
Global\TUSEventU wszystkie wersje
Global\AdvTW32AutoDetectU wszystkie wersje
Global\AdvTW32ReadyXXXWfEventU gdzie XXX jest numerem wersji (np. 450)
Global\MSTKCSrvEventU wszystkie wersje

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:

Nazwa procesu docelowego explorer.exe
Docelowa nazwa u偶ytkownika brak
Docelowy klucz rejestru HKLM\SOFTWARE\Classes\CLSID\{35CEC8A3-2BE6-11D2-8773-92E220524153}\InProcServer32
Nazwa hosta DLL stobject.dll

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:

Wersja MD5 Data kompilacji Rozmiar
4 8d206625957f7c96fd468f6c176248d0 2010.09.15 15:08:17 (GMT) 13312

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

殴ród艂o:
Kaspersky Lab