Paweł Goleń, blog

Niestety, chwilowo NIE BĘDĘ umieszczał odnośników do tekstów na tym blogu, bo prawdopodobnie jest jakiś bug powoduje zawieszenie się bloga, gdy ten próbuje zrobić trackback do samego siebie...

O jakiej zagadce mowa? O dziwnym zachowaniu prawdziwego procesu explorer.exe, który łączył się z wrogim serwerem. Pisałem już o tym wyrażając następujące przypuszczenie:

W takim razie pora to zweryfikować, zwłaszcza, że obraz, który wyłonił się z analizy logu Process Monitora (Tamagotchi XII) jest niekompletny. Brakuje mianowicie informacji o pochodzeniu pliku ise32.exe. Według logów Process Monitora plik ten został utworzony przez... explorer.exe (ten prawdziwy). Jak to się mogło stać?

W Tamagotchi XII pojawia się informacja o dwóch procesach:

• gsxsrdx.exe,
• hheyjo.exe,

Z logów wynika, że procesy te uruchomiły się i zakończyły, nie robiąc nic ciekawego. A przynajmniej tak to wygląda, jeśli popatrzy się wyłączni na aktywność tych dwóch procesów. Prawdopodobnie te dwa pliki mają to samo zadanie (zwracam uwagę, że drugi proces, który był uruchamiany do pary z nimi robił to samo - nadpisywał plik hosts. Obecnie uważam, że procesy te nie robiły "nic", lecz wykazały się sporą przebiegłością - przekonały proces explorer.exe, by robił to, co one mu każą...

Na początku uruchomiony został proces:

24119 21:47:17,5607976 explorer.exe 1684 Process Create C:\WINDOWS\system32\gsxsrdx.exe SUCCESS PID: 1736, Command line: "C:\WINDOWS\system32\gsxsrdx.exe"

Dosłownie kilka chwil później prawdziwy proces explorer.exe tworzy nowy wątek:

Sequence: 26084 21:47:18,0989719 Explorer.EXE 1844 Thread Create SUCCESS Thread ID: 1752 
Sequence: 26084 Date & Time: 2008-05-17 21:47:18 Event Class: Process Operation: Thread Create Result: SUCCESS Path: TID: 1740 Duration: 0.0000000 Thread ID: 1752

Następnie podejrzane operacje wykonywane są właśnie przez ten wątek, na przykład:

Utworzenie katalogu C:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013:

Sequence: 26206 Date & Time: 2008-05-17 21:47:18 Event Class: File System Operation: CreateFile Result: SUCCESS Path: C:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013 TID: 1752 Duration: 0.0002441 Desired Access: Read Data/List Directory, Synchronize Disposition: Create Options: Directory, Synchronous IO Non-Alert Attributes: N ShareMode: Read, Write AllocationSize: 0 OpenResult: Created

Utworzenie pliku C:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\Desktop.ini

Sequence: 26229 Date & Time: 2008-05-17 21:47:18 Event Class: File System Operation: CreateFile Result: SUCCESS Path: C:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\Desktop.ini TID: 1752 Duration: 0.0844548 Desired Access: Generic Write, Read Attributes Disposition: OverwriteIf Options: Synchronous IO Non-Alert, Non-Directory File Attributes: HS ShareMode: None AllocationSize: 0 OpenResult: Created

Utworzenie pliku C:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\ise32.exe

Sequence: 26409 Date & Time: 2008-05-17 21:47:18 Event Class: File System Operation: CreateFile Result: SUCCESS Path: C:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\ise32.exe TID: 1752 Duration: 0.0485757 Desired Access: Generic Write, Read Attributes, Delete Disposition: OverwriteIf Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File Attributes: A ShareMode: None AllocationSize: 0 OpenResult: Created

Ładowanie dodatkowych bibliotek:

Sequence: 46369 Date & Time: 2008-05-17 21:47:24 Event Class: Process Operation: Load Image Result: SUCCESS Path: C:\WINDOWS\system32\mswsock.dll TID: 1752 Duration: 0.0000000 Image Base: 0x71a50000 Image Size: 0x3f000
Sequence: 46384 Date & Time: 2008-05-17 21:47:24 Event Class: Process Operation: Load Image Result: SUCCESS Path: C:\WINDOWS\system32\dnsapi.dll TID: 1752 Duration: 0.0000000 Image Base: 0x76f20000 Image Size: 0x27000
Sequence: 46591 Date & Time: 2008-05-17 21:47:24 Event Class: Process Operation: Load Image Result: SUCCESS Path: C:\WINDOWS\system32\winrnr.dll TID: 1752 Duration: 0.0000000 Image Base: 0x76fb0000 Image Size: 0x8000
Sequence: 46591 Date & Time: 2008-05-17 21:47:24 Event Class: Process Operation: Load Image Result: SUCCESS Path: C:\WINDOWS\system32\winrnr.dll TID: 1752 Duration: 0.0000000 Image Base: 0x76fb0000 Image Size: 0x8000
Sequence: 46927 Date & Time: 2008-05-17 21:47:24 Event Class: Process Operation: Load Image Result: SUCCESS Path: C:\WINDOWS\system32\rasadhlp.dll TID: 1752 Duration: 0.0000000 Image Base: 0x76fc0000 Image Size: 0x6000
Sequence: 46948 Date & Time: 2008-05-17 21:47:24 Event Class: Process Operation: Load Image Result: SUCCESS Path: C:\WINDOWS\system32\hnetcfg.dll TID: 1752 Duration: 0.0000000 Image Base: 0x662b0000 Image Size: 0x58000
Sequence: 46996 Date & Time: 2008-05-17 21:47:24 Event Class: Process Operation: Load Image Result: SUCCESS Path: C:\WINDOWS\system32\wshtcpip.dll TID: 1752 Duration: 0.0000000 Image Base: 0x71a90000 Image Size: 0x8000

Zresztą tego typu podejrzanych wątków jest więcej. Tutaj ciekawie wygląda stos zachowany przez Process Monitor w chwili tworzenia wątku:

0 ntoskrnl.exe ntoskrnl.exe + 0x12346a 0x805fa46a C:\WINDOWS\system32\ntoskrnl.exe 
1 ntoskrnl.exe ntoskrnl.exe + 0xb771d 0x8058e71d C:\WINDOWS\system32\ntoskrnl.exe 
2 ntoskrnl.exe ntoskrnl.exe + 0x77ec 0x804de7ec C:\WINDOWS\system32\ntoskrnl.exe 
3 <unknown> 0x403474 0x403474 4 kernel32.dll kernel32.dll + 0x17067 0x7c817067 C:\WINDOWS\system32\kernel32.dll

Chodzi mi oczywiście o ten fragment unknown. Czyli można praktycznie z całkowitą pewnością stwierdzić, że w obrębie procesu explorer.exe działa złośliwy kod. Wcale nie jest to takie trudne do zrealizowania. W API Windows jest dostępna na przykład taka funkcja: CreateRemoteThread, to pierwsza metoda, która przychodzi mi do głowy.

Wyjaśniło się również przeznaczenie pliku ise32.exe. On również uruchamia się przy logowaniu, a następnie kończy swoje działanie. W tym czasie jednak dokonuje ponownej infekcji procesu explorer.exe. Taka kolejna metoda malware na przeżycie restartu. Usiłowałem prześledzić wykonanie tego procesu, by poznać mechanizm infekcji (potwierdzić swój domysł z wykorzystaniem funkcji CreateRemoteThread, jednak akurat debuggowanie aplikacji nie jest moją najmocniejszą stroną. Tym bardziej, że ise32.exe jest kompresowany/szyfrowany, co dodatkowo podnosi poziom trudności...

Jaki stąd wniosek? Wygląda na to, że sprawdzenie, czy procesy, które są uruchomione w systemie, są "zaufane", to nie wszystko. Nawet w obrębie "zaufanego" procesu może działać wrogi kod. Co więcej jest on trudny do wykrycia. Porównując listę bibliotek z początku i końca monitorowanego okresu czasu (załadowanych do procesu explorer.exe) można znaleźć tylko te nowe biblioteki:

hnetcfg.dll 0x662B0000 0x58000 C:\WINDOWS\system32\hnetcfg.dll 
mswsock.dll 0x71A50000 0x3F000 C:\WINDOWS\system32\mswsock.dll 
wshtcpip.dll 0x71A90000 0x8000 C:\WINDOWS\system32\wshtcpip.dll 
dnsapi.dll 0x76F20000 0x27000 C:\WINDOWS\system32\dnsapi.dll 
winrnr.dll 0x76FB0000 0x8000 C:\WINDOWS\system32\winrnr.dll 
rasadhlp.dll 0x76FC0000 0x6000 C:\WINDOWS\system32\rasadhlp.dll

Nic, co wzbudzałoby specjalne zaniepokojenie. Tym bardziej, że na liście nowych plików, które udało się zidentyfikować, nie było żadnej biblioteki dll. Żadna biblioteka (w sensie pliku na dysku) nie została również zmodyfikowana... Jedyny podejrzany symptom, to handle trzymany przez proces explorer.exe do pliku ise32.exe... Trochę mało. W najbliższym czasie chyba muszę się lepiej przyglądnąć funkcji CreateRemoteThread i ewentualnym śladom, jakie zostawia w systemie jej użycie.

EDIT: Przykład wykorzystania funkcji CreateRemoteThread można znaleźć tutaj.