Flame (znany też jako: Flamer, Skywiper) jest skomplikowaną aplikacją typu koń trojański, odkrytą w 2012 roku. Od tego czasu jest przedmiotem obszernej analizy prowadzonej przez ekspertów od złośliwego oprogramowania. Badacze Flame’a zwracają uwagę przede wszystkim na jego niezwykle skomplikowany kod, modułową konstrukcję i zaawansowane algorytmy, które wykorzystuje. Właśnie stopień skomplikowania tego trojana stał się przyczyną powstania wielu hipotez na temat jego pochodzenia. Jedną z najwcześniejszych publikacji na temat Flame’a jest raport laboratorium CrySyS, który zawiera głównie obserwacje poczynione w trakcie analizy zachowawczej, takie jak: interakcja z systemem operacyjnym, systemem plików, siecią, parametrami czasowymi. Właśnie ten raport zainspirował nas do przyjrzenia się Flame’owi bliżej i odkryciu kilku jego wcześniej nie publikowanych aspektów.

Wstrzykiwanie kodu

Wstrzykiwanie kodu to znana od dawna i popularna wśród twórców złośliwego oprogramowania technika służąca do tego, by rozmieścić jego operacyjne elementy w różnych miejscach systemu operacyjnego: od struktur w ring 3 (np. wstrzykiwanie wątków, hookowanie API) do obiektów jądra (ładowanie sterowników, hookowanie GDT, nadpisywanie pamięci jądra).

Flame także wstrzykuje wątki w trakcie swojego procesu instalacji.

Ale w jego przypadku zwykłe wstrzykiwanie wątków zmieniono w precyzyjne narzędzie pozwalające na transfer własnego kodu do innych procesów i wątków i jest ono intensywnie używane w ciągu całego cyklu życiowego bota Flame’a (od infekcji do samozniszczenia). Flame korzysta z tego narzędzia, by przenosić i kopiować własne elementy w różne części systemu operacyjnego ofiary z zaskakującą sprawnością. W trakcie naszej analizy odkryliśmy ciekawą i rozbudowaną technikę wstrzykiwania wrażliwych części kodu. W tym artykule dzielimy się z czytelnikami szczegółami tego procesu.

Łańcuch wstrzyknięć

Jak możemy przeczytać w raporcie laboratorium CrySyS:

„W trakcie startowania, mssecmgr.ocx jest ładowany jako pakiet uwierzytelniający LSA. Około 2 minuty poźniej, services.exe ładuje moduł advnetcfg.ocx. Proces ten powtarza się co 2, 3 minuty, łącznie 3 razy. Około 2 minuty później, services.exe ładuje moduł nteps32.ocx z mssecmgr.ocx, następnie winlogon.exe również ładuje nteps32.ocx. Ten plik jest ładowany kilka razy. W międzyczasie, explorer.exe tworzy 5 procesów iexplore.exe które tworzą plik wpgfilter.dat.”

– CrySyS Skywiper report, Activation and propagation, Startup sequence, tłum. aut.

Najbardziej interesującym fragmentem tego opisu wydał nam się proces explorer.exe, który nagle uruchamia kilka instancji procesu iexplore.exe. Wyjaśnijmy, co to oznacza: Flame dokonał propagacji swojego kodu przez cztery procesy, by rozpocząć wykonywanie swoich złośliwych funkcji! Zdecydowaliśmy się na dokładniejsze zbadanie tego procesu.

Przeanalizujmy, co działo się w trakcie tego procesu. Komputer ofiary jest infekowany m.in. za pomocą wykorzystania luki MS10-061. Po udanym włamaniu, ładowany jest program rundll32.exe, który z kolei ładuje i rozpoczyna wykonywanie kodu głównego modułu Flame’a – mssecmgr.ocx. Wykonuje on różne operacje instalacyjne (między innymi rejestruje usługę LSA, dzięki której bot załaduje się w trakcie ładowania systemu operacyjnego po zrestartowaniu komputera), a następnie odnajduje proces services.exe i wstrzykuje do niego części swojego kodu.

Następnie, services.exe dystrybuuje za pomocą zwykłych wstrzyknięć kolejne części złośliwego kodu do różnych elementów systemu operacyjnego. Przygotowuje także i wstrzykuje kod do procesu explorer.exe.

Podążyliśmy tropem tego wstrzyknięcia i rozpoczęliśmy analizę także tego procesu. Okazało się, że wstrzyknięty wątek oczekuje na sygnał wydany przez services.exe, a następnie uruchamia proces programu iexplore.exe z zatrzymanym wykonaniem głównego wątku.

Od tej chwili, procesy services.exe i iexplore.exe komunikują się ze sobą za pośrednictwem nazwanego potoku (w naszym przypadku: PipeGx16, jednak możliwe, że ta nazwa została skonstruowana z częściowo wylosowanych znaków i inne instalacje będą dysponować innymi nazwami). Wątek działający w kontekście procesu services.exe zapisuje swoje rozkazy do tego potoku, a iexplore.exe odczytuje je i wykonuje. Jednym z zarejestrowanych przez nas rozkazów jest rozkaz nawiązania połączenia z adresem windowsupdate.microsoft.com, jak pokazano na ilustracjach. Jest to dowód na prowadzenie przez bota Flame złośliwych operacji – ustanawianie ukrytego połączenia. Działanie to może mieć na celu zbadanie, czy komputer ma działające połączenie z Internetem, jak również (co bardziej prawdopodobne) wstęp do tzw. ataku „Gadget”. Proces iexplore.exe działa i wykonuje instrukcje dopóki potok PipeGx16 nie zostanie zamknięty. Jeśli to się stanie, explorer.exe kończy jego działanie.

Unikanie wykrycia

Omawiany proces jest najbardziej wyrafinowaną techniką wstrzykiwania kodu, jaką do tej pory zaobserwowaliśmy w złośliwym oprogramowaniu. Zazwyczaj proces wykonywania złośliwych funkcji (takich jak nawiązywanie ukrytych połączeń) nawet przez zaawansowane trojany bankowe wykorzystywały tylko jedno wstrzyknięcie wątku. Natomiast proces przeprowadzany przez bota Flame, który przeanalizowaliśmy, wykorzystuje aż trzy wstrzyknięcia. Jest to także jeden z dowodów na rozbudowany projekt architektoniczny tej aplikacji. Można jednak zapytać: po co przeprowadzać tą operację w aż tak skomplikowany sposób? Odpowiedź na to pytanie jest oczywista: aby pozostać niewykrytym przez możliwie długi czas. Przyjrzyjmy się znamiennym cechom mechanizmów wstrzyknięć Flame’a.

Przede wszytkim, ukryte połączenie z Internetem jest tworzone przez proces iexplore.exe. W ten sposób Flame unika wykrycia przez zautomatyzowane narzędzia i powierzchowną analizę. Na przykład, połączenie zestawiane przez proces explorer.exe (jak to ma miejsce w przypadku np. bota SpyEye) jest podejrzaną oznaką, dlatego że wykonywanie tego typu połączeń nie leży w kompetencji tego procesu. Przeciwnie ma się sprawa z iexplore.exe, którego głównym zadaniem jest interakcja z siecią.

Także próby połączenia z witryną Windows Update nie wzbudzi podejrzeń nawet w dokładnie obserwowanych segmentach sieciowych korporacji i instytucji rządowych, ponieważ każdy spodziewa się, że systemy Windows będą tam sięgać po aktualizacje. Poza tym, sądzono, że aktualizacje są przecież chronione przez „bezpieczne” funkcje kryptograficzne … Niestety, jak wiadomo, Flame ma sposoby także i na przełamanie tych zabezpieczeń – wspomniany już atak Gadget. Jest to niezwykle wyrafinowany atak wykorzystujący znakomity exploit typu 0day i bardzo trudny do wykrycia.

Także fakt, że proces iexplore.exe jest rozpoczynany i kończony przez explorer.exe, sprawia, że operacje te wyglądają bardzo naturalnie. Zazwyczaj, kiedy użytkownik otwiera swoją ulubioną przeglądarkę, robi to właśnie za pomocą interfejsu explorer.exe. Dlatego Flame wykorzystuje ten proces jako swoiste proxy i pozostawia całą hierarchię procesów nietkniętą.

Podsumowanie

Flame wykorzystuje najbardziej zaawansowany mechanizm wstrzykiwania kodu, jaki do tej pory zaobserwowaliśmy w złośliwym oprogramowaniu. Dystrybuuje on swoje elementy wśród systemowych procesów wykorzystując łańcuchy do trzech wstrzyknięć i propaguje swój kod poprzez cztery procesy, by ostatecznie wykonać funkcje konia trojańskiego. Taka dystrybucja wśród różnych procesów, także z uwzględnieniem ich naturalnej hierarchii znacznie utrudnia wykrycie za pomocą analizy behawioralnej. Ten system to jedna z wielu wyjątkowych cech Flame’a, które pozwoliły mu działać niewykrytym przez miesiące i lata i która zdecydowała o jego szerokim uznaniu.