We wrześniu zeszłego roku Kaspersky Lab rozbił we współpracy z Digital Crimes Unit (DCU) Microsoftu, SurfNET oraz Kyrus Tech, Inc. niebezpieczny botnet Hlux/Kelihos poprzez zasysanie zainfekowanych maszyn do kontrolowanego przez nas hosta.

Kilka miesięcy później nasi analitycy natknęli się na nową wersję szkodliwego oprogramowania odpowiedzialnego za przyłączanie komputerów do botnetu ze znacznymi zmianami w protokole komunikacji oraz nowymi „funkcjami”, takimi jak infekowanie dysków flash czy kradzież portfela bitcoinów.

Z przyjemnością informujemy, że we współpracy z CrowdStrike Intelligence Team, Honeynet Project oraz Dell SecureWorks zdołaliśmy rozbić ten nowy botnet.

W zeszłym tygodniu ustawiliśmy rozproszone na całym świecie maszyny w celu przeprowadzenia operacji zasysania (sinkholing) i w środę 21 marca rozpoczęliśmy zsynchronizowane rozprzestrzenianie adresu IP naszego leja (sinkhole) do sieci peer-to-peer.

Po krótkim czasie nasza maszyna lej zwiększyła swoją „popularność” w sieci – co oznacza, że spora część botnetu komunikuje się tylko z maszyną znajdującą się pod naszą kontrolą:

Rozprzestrzeniliśmy również specjalnie stworzoną listę serwerów zadań. Dzięki temu boty nie mogą żądać nowych poleceń od szkodliwych właścicieli botnetu i co za tym idzie nie mogą być już kontrolowane przez cyberprzestępców.

Jednak kilka godzin po rozpoczęciu naszej operacji właściciele botnetu zareagowali wypuszczeniem nowej wersji swojego bota. Zauważyliśmy również, że właściciele botnetu zaniechali rozsyłania spamu oraz przeprowadzania ataków DDoS za pośrednictwem swojej sieci.

Po sześciu dniach mamy teraz 116 000 botów łączących się z naszym lejem.

Poniżej przedstawiamy podział według wersji systemu operacyjnego:

Większość botów jest zlokalizowanych w Polsce i w Stanach Zjednoczonych:

Tło

Najważniejsze zmiany w stosunku do starego botnetu Hlux miały miejsce w protokole komunikacyjnym. W najniższej warstwie szkodliwi twórcy zmienili kolejność szyfrowania oraz metody pakowania.

№	Stary Hlux	Nowy Hlux
1	Blowfish z key1	Blowfish z nowym key1
2	3DES z key2	Rozpakowywanie przy pomocy Zlib
3	Blowfish z key3	3DES z nowym key2
4	Rozpakowywanie przy pomocy Zlib	Blowfish z nowym key3

Tabela pochodzi z postu Marii

Naturalnie autorzy tego szkodliwego oprogramowania zmienili klucze szyfrowania, jak również klucze RSA wykorzystywane do podpisywania części wiadomości wysyłanych poprzez sieć p2p.

	Stary Hlux	Nowy Hlux
Controllers’ IP	RSA key1	Nowy RSA key1
Update/Exec urls1	RSA key1	Nowy RSA key1
Update/Exec urls2	RSA key2	Nowy RSA key2

Tabela pochodzi z postu Marii

P: Czym jest botnet Hlux/Kelihos?
O: Kelihos to stosowana przez Microsoft nazwa botentu określanego przez Kaspersky Lab jako Hlux. Hlux jest botnetem peer-to-peer o architekturze podobnej do tej stosowanej dla botnetu Waledac. Składa się z warstw różnych rodzajów węzłów: kontrolerów, ruterów i pracowników.

P: Co to jest botnet peer-to-peer?
O: W przeciwieństwie do klasycznego botnetu, botnet peer-to-peer nie wykorzystuje scentralizowanego serwera kontroli (C&C). Każdy członek sieci może działać jako serwer oraz/lub klient. Z punktu widzenia szkodliwego użytkownika zaletami takiej struktury jest pominięcie centralnego C&C jako pojedynczego punktu awarii. Z naszego punktu widzenia tego rodzaju botnet jest znacznie trudniejszy do zniszczenia.

Architektura tradycyjnego botnetu oraz botnetu P2P:

P: Kiedy Hlux/Kelihos został po raz pierwszy wykryty na wolności?
O: Pierwsza wersja została dostrzeżona na wolności już w grudniu 2010 r. Nasz pierwszy post na blogu dotyczący botnetu Hlux pochodzi ze stycznia 2011 r. Pierwszy znany wpis na blogu został opublikowany przez ShadowServer w grudniu 2010 r. Nowa wersja pojawiła się tuż po naszej pierwszej operacji leja we wrześniu 2011 r.

P: Czym różni się stare i nowe szkodliwe oprogramowanie botnetu Hlux/Kelihos?
O: Starsza wersja była wykorzystywana do rozprzestrzeniania spamu i potrafiła przeprowadzać ataki DDoS (distributed denial-of-service). W nowej wersji odkryliśmy, że:

• Bot potrafi infekować dyski flash, tworząc na nich plik o nazwie „Copy a Shortcut to google.Ink” w ten sam sposób co Stuxnet.
• Bot potrafi wyszukiwać pliki konfiguracji dla wielu klientów FTP i przenosić je do serwerów kontroli.
• Bot posiada wbudowaną funkcję kradzieży portfela Bitcoin.
• Bot zawiera również funkcję kopalni Bitcoin.
• Bot może działać w trybie serwera poxy.
• Bot przeszukuje dyski twarde w celu znalezienia plików zawierających adresy e-mail.
• Bot posiada sniffera przechwytującego hasła do poczty e-mail, sesji FTP oraz HTTP.

Twórca nowej wersji botnetu Hlux zmienił również protokół komunikacji:

• Zmienił kolejność szyfrowania i metody kompresji
• Dodał nowe klucze szyfrowania (wiadomości sieci p2p) oraz klucze RSA (do podpisywania części szkodliwej funkcji wiadomości)
• Nazwy pól w szkodliwej funkcji składają się teraz z 1-2 znaków, bez hashów.

P: Czy „nowy botnet Hlux/Kelihos” został odbudowany na „starym” botnecie, który został rozbity we wrześniu zeszłego roku?

O: Tak, szkodliwe oprogramowanie zostało stworzone przy użyciu tego samego kodowania co w przypadku pierwotnego botnetu Hlux/Kelihos. Nowy szkodnik pokazał, że drugi botnet został nieco zaktualizowany: dodano metody infekcji, funkcję kopalni Bitcoin oraz funkcję kradzieży portfela. Podobnie jak w pierwszej wersji, botnet wykorzystywał również swoją sieć zainfekowanych komputerów do wysyłania spamu, kradzieży danych osobistych oraz przeprowadzania ataków DDoS na konkretne cele.

Warto zauważyć, że botnet Hlux, który został rozbity przez nas wcześniej, nadal znajduje się pod naszą kontrolą, a zainfekowane maszyny nie otrzymują poleceń.

W jaki sposób twórcy szkodliwego oprogramowania zdołali stworzyć nowy botnet w tak krótkim czasie – tego dokładnie nie wiadomo. Właściciele botów zwykle odbudowują botnety przy użyciu szkodliwych usług „pay-per-install”.

P: Co oznacza „sinkholing” (zasysanie)?
O: W tym przypadku oznacza to działania, które prowadzą do dużej popularności specjalnego peera w sieci peer-to-peer. Ten specjalny peer znajduje się pod naszą kontrolą i dostarcza łączącym botom specjalnie stworzone listy zadań uniemożliwiające kontrolowanie botów przez pierwotnego szkodliwego właściciela botnetu.

P: Ile botów znajduje się w starym i nowym botnecie Hlux/Kelihos?
O: Rozmiar botnetu peer-to-peer można jedynie oszacować. Dla starego botnetu Hlux, który rozbiliśmy we wrześniu 2010 r., oszacowaliśmy około 40000 różnych adresów IP. Dla nowego botnetu, szacujemy około 110 000 adresów IP.

P: W których państwach znajduje się najwięcej infekcji Hlux/Kelihos?
O: W przypadku starej wersji botnetu Hlux, najwięcej połączeń trafiło do naszego leja z Tajlandii, Wietnamu, Indii oraz Korei.

Dla nowej wersji rozkład infekcji wygląda następująco:

P: Kto uczestniczył w niedawnym rozbiciu omawianego botnetu (marzec 2012)?
O: W operacji tej Kaspersky Lab współpracował z zespołami badawczymi z CrowdStrike, HoneyNet Project oraz Dell SecureWorks.

P: Co mogą zrobić użytkownicy, w przypadku gdy ich system jest zainfekowany szkodliwym oprogramowaniem z tego botnetu?
O: Mimo że pierwsze dwa botnety Kelihos/Hlux zostały rozbite, wiele komputerów nadal jest zainfekowanych szkodliwym oprogramowaniem. Zalecamy odwiedzenie strony http://support.kaspersky.com/viruses/utility w celu pobrania darmowych narzędzi oferowanych przez Kaspersky Lab, przy pomocy których można wyczyścić komputer z tego szkodnika.

Więcej informacji, łącznie z tym, jak chronić komputer, można znaleźć na stronie http://support.kaspersky.com/viruses.

Dopóki gangi botnetowe nie zostaną całkowicie rozbite, nieustannie będą pojawiały się nowe botnety z uaktualnionym szkodliwym oprogramowaniem, infekując komputery.

P: Boty obu botnetów są obecnie zasysane do maszyn znajdujących się pod waszą kontrolą. Co teraz?
O: Jest to główne pytanie, jakie zadaliśmy sobie podczas pierwszego rozbijania botnetu jeszcze we wrześniu 2011 r. Z pewnością nie możemy zasysać Hluxa bez końca. Stosowane obecnie metody stanowią rozwiązanie tymczasowe, nie eliminują jednak całkowicie problemu, ponieważ jedyne rzeczywiste rozwiązanie polega na wyczyszczeniu zainfekowanych maszyn. Spodziewamy się, że z czasem liczba maszyn zasysanych przez nasz lej będzie powoli spadać w miarę usuwania infekcji z komputerów oraz przeinstalowywania systemów.

Jest jeszcze jeden teoretyczny sposób ostatecznego pozbycia się botnetu Hlux. Ponieważ wiemy, jak działa proces aktualizacji bota, moglibyśmy wykorzystać tę wiedzę, aby wydać własną aktualizację, która usuwa infekcje i dokonuje samozniszczenia. Jednak w większości państw byłoby to niezgodne z prawem.

Jedynym rozwiązaniem, które może mieć trwałe skutki, jest apelowanie do polityków, aby uchwalali więcej międzynarodowych ustaw zapewniających większą współpracę między specjalistami ds. cyberbezpieczeństwa oraz federalnymi organami ścigania. Sinkholing jest rozwiązaniem tymczasowym. Problem botnetów można rozwiązać permanentnie jedynie poprzez zidentyfikowanie odpowiedzialnych za nie grup oraz umożliwienie aresztowania ich przez organy ścigania. Nowe przepisy zapewnią większą jurysdykcję stosowania następujących środków:

• przeprowadzanie masowej naprawy za pośrednictwem botnetu
• wykorzystywanie doświadczenia i badań firm prywatnych, zapewniając im immunitet przed ustawami o cyberprzestępczości w konkretnym dochodzeniu
• Wykorzystywanie zasobów dowolnego zainfekowanego systemu podczas dochodzenia
• uzyskanie nakazu zdalnego wykorzystania systemu w przypadku braku innej alternatywy

Po rozbiciu starego botnetu Hlux zapytaliśmy czytelników na stronie securelist.com, w jaki sposób Kaspersky Lab powinien postąpić z tym botnetem: odpowiedź była dość jednoznaczna. Tylko 4% głosowało za rozwiązaniem „Zostawcie botnet w spokoju”, 9% wybrało opcję „Kontynuujcie zasysanie i przekażcie logi adresów IP odpowiednim kontaktom, tak aby mogli podjąć działania”, a 85% głosowało za opcją „Zastosujcie rozwiązanie, które usunie infekcje”. W sondażu oddano 8539 głosów.

Niedawno w Szwecji dokonano dużego oszustwa bankowego, w wyniku którego na skutek zainfekowania komputerów skradziono ponad 1,2 miliona koron szwedzkich (około 177 800 dolarów). Osoby atakujące wykorzystały trojana, który został wysłany ofiarom i – po zainstalowaniu – umożliwił im uzyskanie dostępu do zainfekowanych komputerów. Na szczęście osoby odpowiedzialne za ten atak zostały złapane i otrzymały wyrok pozbawienia wolności, jednak minęło trochę czasu, zanim śledztwo zostało doprowadzone do końca, ponieważ w oszustwie tym brało udział ponad 10 osób.

Możliwe, że ataki te nie są już tak skuteczne, jak życzyliby sobie tego cyberprzestępcy, ponieważ obecnie stosują inne metody wyszukiwania i wykorzystywania nowych ofiar. Od jakiegoś czasu możemy zaobserwować, że cyberprzestępcy wykorzystują „porwane” konta na Facebooku, aby podstępnie nakłaniać znajomych tych, których konta zostały porwane, do wykonywania różnych działań, od klikania szkodliwych odsyłaczy po przelewanie pieniędzy na konta bankowe cyberprzestępców.

Należy zaznaczyć, że nie jest to nowe oszustwo – takie incydenty obserwujemy już od długiego czasu. Teraz jednak wykorzystywanie skradzionych/porwanych, lub fałszywych, kont staje się bardzo powszechne na Facebooku. Tak powszechne, że istnieją nawet firmy tworzące fałszywe konta, które następnie sprzedają dostęp do nich innym cyberprzestępcom. Jak można się spodziewać, im więcej znajomych mają właściciele kont, tym są droższe są takie konta, ponieważ za ich pośrednictwem można złowić więcej osób.

W tym przypadku problem nie jest jedynie techniczny – przede wszystkim jest to problem społeczny. Facebooka używamy po to, żeby rozszerzyć nasze grono znajomych. Na tym portalu można mieć bez trudu kilkaset znajomych, podczas gdy w życiu realnym – zaledwie 50. Może to stanowić problem, ponieważ niektóre z ustawień bezpieczeństwa i prywatności na Facebooku mają zastosowanie tylko do interakcji z osobami, które nie są naszymi znajomymi. Z kolei nasi znajomi posiadają pełny dostęp do wszystkich informacji o nas.

Ostrzegamy użytkowników przed tym nowym scamem. Oszuści wykorzystują skradzione lub porwane konta, aby wysyłać swoim ofiarom osobiste wiadomości. Udają, że mają problem, twierdząc na przykład, że utknęli na lotnisku i potrzebują kilkuset koron na nowy bilet powrotny. Mogą też wmawiać swojej ofierze, że zepsuł się ich token umożliwiający transakcje bankowości online, i poprosić ją, aby pożyczyła swój własny. Wydaje się to dość trywialne, ale zauważyliśmy, że wiele osób nie jest świadomych tego, że token bankowy jest urządzeniem prywatnym i nie może być wykorzystywany z innym kontem.

Koncepcja, na jakiej opiera się to oszustwo, jest dość prosta. Wykorzystuje ona to, że na Facebooku publikowana jest ogromna ilość informacji osobistych. Cyberprzestępcy mogą z łatwością wywnioskować wiele informacji o danej osobie. Jeżeli wykorzystują skradzione konto, mogą również z łatwością przyjrzeć się naturze relacji między jedną ofiarą a drugą.

Chcielibyśmy uświadomić użytkownikom to zagrożenie, tak aby zastanowili się, zanim ujawnią jakiekolwiek informacje dotyczące kont bankowych lub pożyczą komuś pieniądze. Oto kilka prostych wskazówek:

• Upewnij się, że osoba, z którą rozmawiasz, naprawdę jest tym, kim sądzisz, że jest. Możesz zadzwonić do niej na numer jej telefonu komórkowego lub skontaktować się z jej krewnymi, aby sprawdzić, czy rzeczywiście jest za granicą.
• Nigdy nie podawaj przez Internet żadnych poufnych danych dotyczących bankowości.
• Nie dodawaj ani nie akceptuj żadnych zaproszeń do grona znajomych od osób, których nie znasz.
• Upewnij się, że posiadasz ochronę przed szkodliwym oprogramowaniem zainstalowaną na komputerze.
• Pamiętaj o częstej zmianie haseł i postaraj się, aby były złożone i trudne do odgadnięcia – stosuj kombinację liter, liczb i symboli. Nie stosuj na Facebooku tego samego hasła, jakie masz na innych stronach: jeżeli hasło zostanie złamane na jednej z tych stron, będzie mogło zostać wykorzystane do uzyskania dostępu do twojego konta na Facebooku.

W ostatnich dniach został wykryty szkodliwy program z ważną sygnaturą. Szkodnik ten jest 32- lub 64-bitowym dropperem, wykrywanym przez Kaspersky Lab odpowiednio jako Trojan-Dropper.Win32.Mediyes lub Trojan-Dropper.Win64.Mediyes.

Zidentyfikowano liczne pliki droppera z podpisami o różnych datach od grudnia 2011 do 7 marca 2012 r. We wszystkich tych przypadkach został użyty certyfikat wydany dla szwajcarskiej firmy Conpavi AG. Firma ta współpracuje ze szwajcarskimi organami rządowymi, takimi jak samorządy miejskie czy kantony.

Nie znamy jeszcze dokładnego źródła szkodnika Trojan-Dropper.Win32/Win64.Mediyes, mamy jednak przesłanki, aby przypuszczać, że jest on instalowany na komputerach przy pomocy exploitów.

32-bitowy dropper przechowuje swój własny 32-bitowy sterownik – którego nazwa zaczyna się od ‘HID’ – w folderze sterowników systemowych. Następnie dropper usuwa się z systemu. Sam sterownik nie jest podpisany, to jednak nie przeszkadza mu działać poprawnie w 32-bitowym systemie Windows. Sterownik zawiera bibliotekę DLL, która jest kopiowana do foldera systemowego rozpoczynającego się od liter ‘PNG’. Główną funkcją sterownika jest wstrzykiwanie biblioteki DLL do procesu przeglądarki internetowej. Sterownik ukrywa również na dysku komponenty Mediyes.

64-bitowy dropper nie zawiera sterownika i wstrzykuje bibliotekę DLL bezpośrednio do przeglądarki.

Szkodliwa biblioteka DLL jest wykrywana przez Kaspersky Lab jako Trojan.Win32.Mediyes, a sterownik jako Rootkit.Win32.Mediyes.

Po uruchomieniu biblioteka DLL sprawdza, w jakiej przeglądarce działa, a następnie zaczyna przechwytywać żądania przeglądarki wysyłane do wyszukiwarek Google, Yahoo! oraz Bing. Duplikuje wszystkie żądania na zlokalizowanym w Niemczech serwerze szkodliwych użytkowników. Zapytania są wykorzystywane przez cyberprzestępców do zarabiania pieniędzy w ramach programu partnerskiego „Search 123” działającego na zasadzie PPC (pay-per-click). Serwer odpowiada na żądania użytkowników z odsyłaczami z systemu Search123, które są klikane bez wiedzy użytkownika. W ten sposób szkodliwi użytkownicy zarabiają na fałszywych kliknięciach.

Według danych KSN, Trojan.Win32.Mediyes został wykryty na komputerach około 5 000 unikatowych użytkowników, głównie w Europie Zachodniej – w Niemczech, Szwajcarii, Szwecji, Francji i we Włoszech.

Celem tego szkodnika są bez wątpienia użytkownicy w Europie Zachodniej. Świadczą o tym inne dowody – certyfikat wydany przez szwajcarską firmę, serwer zlokalizowany w Niemczech oraz przechwytywanie jedynie żądań dokonywanych na najpopularniejszych wyszukiwarkach.

Poinformowaliśmy VeriSign o zagrożeniu i poprosiliśmy o unieważnienie zhakowanych certyfikatów.

Podczas analizy komponentów Duqu odkryliśmy interesującą anomalię w głównym komponencie odpowiedzialnym za jego logikę biznesową – szkodliwą funkcję (Payload DLL). Chcielibyśmy podzielić się naszymi odkryciami i poprosić o pomoc w zidentyfikowaniu kodu.

Struktura kodu

Na pierwszy rzut oka Payload DLL wygląda jak zwykły plik Windows PE DLL skompilowany przy użyciu Microsoft Visual Studio 2008 (wersja linkera 9.0). Kod punktu wejścia jest całkowicie standardowy, jest też jedna funkcja eksportowana przez liczebnik porządkowy 1, która również wygląda jak MSVC++. Funkcja ta jest wywoływana z PNF DLL i w rzeczywistości stanowi „główną” funkcję, która implementuje całą logikę kontaktowania się z serwerami C&C, otrzymując dodatkowe moduły funkcji szkodliwej oraz wykonując je. Najciekawsze jest to, w jaki sposób logika ta została zaprogramowana i jakie wykorzystano narzędzia.

Sekcja kodu Payload DLL jest typowa dla kodu binarnego, który został stworzony z kilku kawałków kodu. Składa się z „plastrów” kodu, które początkowo mogły zostać skompilowane w osobne pliki obiektowe, które następnie zostały połączone w jedną bibliotekę DLL. Większość z nich można znaleźć w dowolnym programie C++, jak funkcje STL (Standard Template Library), funkcje biblioteki dynamicznej oraz kod napisany przez użytkownika, z wyjątkiem największego plastra, który zawiera większość kodu odpowiedzialnego za interakcję z serwerem C&C.

Plaster ten różni się od innych, ponieważ nie został skompilowany ze źródeł C++. Nie zawiera żadnych odnośników do standardowych ani napisanych przez użytkownika funkcji C++, jednak bez wątpienia jest to kod obiektowy. Nazwaliśmy go Szkieletem Duqu.

Szkielet

Funkcje

Kod implementujący Szkielet Duqu posiada kilka wyróżniających go cech:

• Wszystko ma postać obiektów
• Tablica funkcji jest umieszczona bezpośrednio w instancji klasy i może zostać zmodyfikowana po skonstruowaniu
• Nie ma rozróżnienia pomiędzy klasami narzędzi (powiązane listy, hashe) a kodem napisanym przez użytkownika
• Obiekty komunikują się przy użyciu wywołań metod, kolejek opóźnionego wykonania, a nawet wywołań zwrotnych spowodowanych wydarzeniem
• Nie ma odwołań do funkcji biblioteki dynamicznej, zamiast tego wykorzystywane jest natywne API Windows

Obiekty

Wszystkie obiekty są instancjami pewnej klasy. Zidentyfikowaliśmy 60 klas. Każdy obiekt jest tworzony przy użyciu funkcji konstruktora, która przydziela pamięć, wypełnia tablicę funkcji i inicjuje składniki.

Struktura każdego obiektu zależy od jego klasy. Niektóre klasy wydają się mieć binarne kompatybilne tablice funkcji, nic jednak nie wskazuje na to, że posiadają wspólne klasy macierzyste (jak w innych językach obiektowych). Ponadto, lokalizacja tablicy funkcji nie jest stała: niektóre klasy mają ją na pozycji 0 instancji, inne nie.

Obiekty są niszczone przez odpowiednie funkcje destruktora. Funkcje te zwykle niszczą wszystkie obiekty, do których odwołują się pola składowe, i zwalniają wykorzystaną pamięć.

Odwoływanie do funkcji składowych może następować poprzez tablicę funkcji obiektu (tak jak funkcji „wirtualnych” w C++) lub mogą one być wywoływane bezpośrednio. W większości języków obiektowych funkcje składowe otrzymują parametr „this”, który odwołuje się do instancji obiektu i istnieje konwencja, która określa lokalizację parametru – w rejestrze lub w stosie. W przypadku klas Szkieletu Duqu jest inaczej – mogą one otrzymać parametr „this” w dowolnym rejestrze lub stosie.

Szkielet oparty na zdarzeniach

Struktura i implementacja obiektów w Szkielecie Duqu zdecydowanie nie jest natywna względem C++, który został wykorzystany do zaprogramowania reszty trojana. Można wyróżnić jeszcze bardziej interesującą cechę tego szkieletu występującą w całym kodzie: jest on oparty na zdarzeniach.

Istnieją specjalne obiekty, które implementują model oparty na zdarzeniach:

• obiekty zdarzeń oparte na natywnych uchwytach API Windows
• obiekty kontekstu wątków, które prowadzą listy zdarzeń i kolejki opóźnionego wykonania
• obiekty odwołania zwrotnego, które są powiązane ze zdarzeniami
• monitory zdarzeń stworzone przez każdy kontekst wątków w celu monitorowania zdarzeń oraz wykonywania obiektów odwołania zwrotnego
• zbiornik kontekstu wątków zarządza listą aktywnych wątków i zapewnia dostęp do obiektów według kontekstu wątku

Ten model oparty na zdarzeniach przypomina Objective C oraz jego funkcje przekazywania wiadomości, jednak kod nie posiada żadnych bezpośrednich odniesień do tego języka, ani nie wygląda jakby został skompilowany przy pomocy znanych kompilatorów Objective C.

Każdy obiekt kontekstu wątków może rozpocząć „główną pętlę”, która szuka i przetwarza nowe pozycje na listach. Większość kodu Duqu opiera się na tej samej zasadzie: tworzy obiekt, wiąże kilka odwołań zwrotnych z wewnętrznymi lub zewnętrznymi zdarzeniami i wraca. Następnie uchwyty odwołań zwrotnych są wykonywane przez obiekt monitorowania zdarzeń, który jest tworzony w każdym kontekście wątków.

Poniżej przykład pseudokodu dla obiektu portu:

SocketObjectConstructor {

NativeSocket = socket();

SocketEvent = new MonitoredEvent(NativeSocket);

SocketObjectCallback = new ObjectCallback(this, SocketEvent, OnCallbackFunc);

connect(NativeSocket, ...);

}

OnCallbackFunc {

switch(GetType(Event)) {

case Connected: ...

case ReadData: ...

...}

}

Wnioski

• Szkielet Duqu wydaje się być napisany w nieznanym języku programistycznym.
• W przeciwieństwie do pozostałej części ciała Duqu, nie jest to język C++ i nie został skompilowany przy pomocy Visual C++ 2008 Microsoftu.
• Architektura oparta w wysokim stopniu na zdarzeniach wskazuje na kod stworzony z myślą o wykorzystywaniu w niemal każdym rodzaju warunków, łącznie z komutacjami asynchronicznymi.
• Biorąc pod uwagę rozmiar projektu Duqu, nie można wykluczyć, że za szkielet odpowiadał inny zespół niż ten, który stworzył sterowniki i napisał infekcję systemu oraz exploity.
• Tajemniczym językiem programowania z pewnością nie jest C++, Objective C, Java, Python, Ada, Lua i wiele innych języków, które sprawdziliśmy.
• W porównaniu ze Stuxnetem (który cały został napisany w MSVC++), jest to jedna z cech charakterystycznych szkieletu Duqu.

Szkielet Duqu: Co to było?

Po długiej analizie jesteśmy w 100% pewni, że Szkielet Duqu nie został zaprogramowany przy użyciu języka Visual C++. Możliwe, że jego autorzy wykorzystali stworzony przez siebie szkielet w celu wygenerowania pośredniego kodu c lub użyli całkowicie innego języka programowania.

Apelujemy do społeczności programistów i prosimy każdego, kto rozpoznaje ten szkielet, zestaw narzędzi lub język programowania, który może wygenerować podobne konstrukcje kodu, o skontaktowanie się z nami lub napisanie komentarza na blogu. Wierzymy, że z waszą pomocą możemy rozwikłać tajemnicę historii Duqu.