Jesienią 2011 roku zarejestrowano infekcje nowym złośliwym oprogramowaniem. Analiza mechanizmu uruchamiania złośliwego oprogramowania, proces jego ukrywania, czy też sposób składowania konfiguracji wskazywały na ZeuSa. Jednak podczas monitorowania zainfekowanych maszyn nie udało się zauważyć charakterystycznej dla tego trojana komunikacji z centrum C&C. Po głębszej analizie okazało się, iż próbka to najprawdopodobniej nowa wersja trojana ZeuS oparta na upublicznionym przypadkiem kodzie.

W nowej wersji trojana autorzy skupili się na eliminacji najsłabszego ogniwa – scentralizowanego systemu dystrybucji informacji.
Poprzednie wersje ZeuS-a oparte było o jeden (lub kilka) zdefiniowanych adresów, pod którymi dostępne było centrum zarządzania C&C. Pozwalało to łatwo namierzyć takie adresy i poprzez ich blokowanie uczynić botnet bezużytecznym. Badany wariant trojana wykorzystuje dwa nowe kanały komunikacyjne do pobierania nowych rozkazów (rys. po prawej):

1. Komunikacja w sieci peer-to-peer
2. Mechanizm Generowania Domen

W internecie dostępne były już wcześniej informacje na temat nowego wariantu zeusa (np: abuse.ch), ale – z informacji jakie posiadamy – dotychczasowa praca badawcza skupiała się na zarejestrowaniu i monitorowaniu ruchu do domen zeusowych. Podczas naszej pracy skupiliśmy się na poznaniu oraz monitorowaniu mechanizmów wymiany informacji przez sieć P2P oraz próbie zebrania danych na temat jej kształtu.

Mechanizm wymiany informacji przez siec Zeus-peer-to-peer (dalej ZP2P)

rys.1: Wizualizacja sieci ZP2P (10 000 węzłów)

W przypadku modelu opartego na centralnym (jednym – lub wielu) punkcie zarządzania, z góry wiadomo jakie komputery wykorzystywane są do wydawania rozkazów. Nowy mechanizm dystrybucji informacji oparty jest o bezpośrednią wymianę danych między zainfekowanymi komputerami – czyli model komunikacji Peer-to-peer. Brak centralnego węzła zarządzającego w tym modelu powoduje, iż znacznie trudniej jest znaleźć komputery dystrybuujące nowe rozkazy – a zablokowanie kanału wymiany danych jest praktycznie niemożliwe. Dobrze ilustruje to graf na rys. 1. Widać, iż w przedstawionej sieci brak jest centralnego punku (jednego, czy też wielu), a połączenia między komputerami mają charakter losowy.

Jak działa sieć ZP2P?

Sieć ta najprawdopodobniej jest oparta na standardzie protokołu Kademlia. Pojedynczy komputer (węzeł) w sieci ZP2P identyfikowany jest za pomocą unikalnego identyfikatora UID – który generowany jest podczas pierwszego uruchomienia złośliwego oprogramowania. Każdy z komputerów należących do sieci ZP2P posiada w pamięci „tablicę sąsiadów”. Zawiera ona listę ok 30 pobliskich węzłów w sieci ZP2P – ich identyfikator UID , adres IP oraz numer portu UDP. Lista ta jest wykorzystywana do wymiany danych oraz informacji.
W sieci ZeuS-p2p możemy wyróżnić dwa rodzaje komunikacji:

• Wymiana informacji (z użyciem protokołu UDP) :
  • (QV) Wymiana informacji o posiadanej przez komputer wersji pliku konfiguracyjnego
  • (QN) Wymiana informacji o węzłach znajdujących się w „tablicy sąsiadów” danego komputera
• Wymiana danych binarnych (z użyciem protokółu TCP)
  • Dystrybucja nowych plików konfiguracyjnych

Wykresy 2 oraz 3 przedstawiają rozkład numerów portów wykorzystywanych do komunikacji w sieci ZP2P.

wyk.2: Rozkład numerów portów UDP w sieci ZP2P (800 000 próbek)

wyk.3: Rozkład numerów portów TCP w sieci ZP2P (100 000 próbek)

W przypadku komunikatu typu QN jednorazowo przesyłane jest tylko 10 rekordów z „tablicy sąsiadów”. Ten rodzaj komunikacji służy uaktualnianiu lokalnej tablicy sąsiadów w sieci ZP2P. Po wykonaniu zapytania QN bot zapisuje informacje o sąsiednich węzłach, których identyfikator UID jest zbliżony do identyfikatora (XOR) lokalnego komputera

Komunikaty typu QV służą sprawdzeniu oraz propagacji informacji o nowych wersjach plików konfiguracyjnych. Jeżeli węzeł, który wykonał zapytanie QV posiada wersję konfiguracji starszą, niż wersja podana w odpowiedzi na to zapytanie – wykona on połączenie TCP do zdalnego komputera prosząc o przesłanie nowszej wersji konfiguracji.

Wykresy 4 oraz 5 przedstawiają rozkład ilości dzieci oraz ilości rodziców w sieci ZP2P. Dane pochodzą z analizy odpowiedzi botów na zapytania typu QN w przeciągu 3 tygodni. Ilość dzieci (czyli ilość różnych wpisów w tablicy sąsiedztwa) może przekraczać wartość 30, ponieważ (jak już zostało to opisane) tablica sąsiedztwa ulegać może częstym aktualizacjom.

wyk.4: Rozkład ilości dzieci

wyk.5: Rozkład ilości rodziców

Monitorowanie sieci ZP2P

W laboratorium CERT Polska przeprowadziliśmy mapowanie sieci ZP2P poprzez monitorowanie odpowiedzi na komunikaty typu QN. Zebrane w ten sposób adresy IP naniesione zostały na mapę:

Mapa gęstości ilości komputerów zainfekowanych nowym wariantem trojana

Mechanizm DGA (generowanie nazw domenowych)

Jeżeli mechanizm komunikacji w sieci ZP2P zostanie zablokowany (np: poprzez zablokowanie odpowiednich portów TCP i UDP na firewallu) – bot automatycznie przełącza się na zapasowy kanał komunikacyjny – DGA. Mechanizm DGA jest kolejnym elementem zaimplementowanym w nowej wersji trojana, który znacznie utrudnia poszukiwania oraz odcięcie osoby zarządzającej botnetem.
Polega on na generowaniu pewnej długiej listy nazw domenowych w oparciu o określone parametry, a następnie próbie komunikacji z każdą z wygenerowanych domen. Parametry mechanizmu DGA umieszczone są w kodzie trojana – oraz znane są tylko botmasterowi. Może on własnoręcznie wygenerować taką listę, wybrać z niej jedną pozycje – a następnie zarejestrować wybraną domenę i czekać na próby połączeń z zainfekowanych komputerów.

rys. 6 Generowanie zeusowych domen

ZeuS-owe DGA

W przypadku botnetu ZeuS, parametrem dla mechanizmu DGA jest bieżąca data. Lista domen zawiera 1000 pozycji i zmienia się co 7 dni. Każda z nazw składa się z ciągu znaków o długości od 32 do 48 oraz jednej z TLD: ru,com,biz,info,net lub org. Warto zaznaczyć, iż w nazwie nie występuje znak „-„. Poniżej znajduje się wyrażenie regularne pozwalające na wyszukanie domen zeusowych w logach :

rys.7: Dodane wyjątki w konfiguracji systemowego firewalla

Jak rozpoznać infekcję nowym ZeuSem?

Obecność nowego wariantu zeusa na komputerze można rozpoznać przede wszystkim poprzez monitorowanie ruchu sieciowego. Jak widać na rys.8 – przy użyciu narzędzia TCPview można zauważyć nowe otwarte porty TCP i UDP procesu explorer.exe. Dodatkowo, aby umożliwić komunikację z siecią ZP2P, trojan dodaje do systemowego firewalla nowe reguły. Jak widać na rys. 7 są to dwa nowe wyjątki pozwalające na nawiązywanie połączeń na określonych portach TCP i UDP. Zakres tych portów odczytać można z wykresów 2 i 3.

rys.8: Otwarte porty TCP i UDP wykorzystywane do komunikacji P2P

UPDATE:

Skróty MD5 analizowanych próbek :