Mając ten komfort, że nikt nie będzie mi zarzucał naruszenie stanu obiektu badań, uruchomiłem na zainfekowanym systemie kilka narzędzi, które za zadanie miały zebrać pewne informacje o tym, co się w nim dzieje.
Tamagotchi VI: co widać na żywo
Listę zalogowanych użytkowników można uzyskać przy pomocy dwóch narzędzi (między innymi oczywiście):
- psloggedon,
- logonsessions,
Oba narzędzia oczywiście z Sysinternals Suite.
Psloggeon wykazał następujących zalogowanych użytkowników:
- NT AUTHORITY\LOCAL SERVICE
- NT AUTHORITY\NETWORK SERVICE
- MALWAREHUNTER\Administrator
- NT AUTHORITY\SYSTEM
Wszyscy ci użytkownicy są standardowymi użytkownikami, a to oznacza, że malware nie założyło innych kont, a przynajmniej nie uruchomiło w ich kontekście żadnych procesów.
Logonsessions oprócz listy zalogowanych sesji, dostarcza również informacji o uruchomionych w ich obrębie procesach. Szczególnie ciekawy fragment dotyczy użytkownika Administrator: [5] Logon session 00000000:0000c0de: User name: MALWAREHUNTER\Administrator Auth package: NTLM Logon type: Interactive Session: 0 Sid: S-1-5-21-448539723-1383384898-842925246-500 Logon time: 2008-05-17 21:42:20 Logon server: MALWAREHUNTER DNS Domain: UPN: 1844: C:\WINDOWS\Explorer.EXE 1920: C:\WINDOWS\system32\wscntfy.exe 2040: C:\Program Files\Virtual Machine Additions\vmusrvc.exe 216: C:\WINDOWS\system32\ctfmon.exe 336: C:\WINDOWS\system32\cmd.exe 1684: C:\WINDOWS\system32\explorer.exe 1772: C:\WINDOWS\system32\iexplore.exe 2020: C:\WINDOWS\system32\pwpveix.exe 1320: C:\WINDOWS\system32\ygcpzaf.exe 1156: C:\Program Files\sysinternals\logonsessions.exe Można na tym zrzucie zauważyć cztery dziwne procesy:
- 1684 - plik explorer.exe znajduje się w ścieżce %systemroot%\explorer.exe, a nie %systemroot%\system32\explorer.exe,
- 1772 - plik iexplore.exe znajduje się w %programfiles%, a nie w %systemroot% (katalogi pomijam),
- 2020 - plik pwpviex.exe nic mi nie mówi,
- 1320 - plik ygcpzaf.exe nic mi nie mówi,
Oznacza to, że w systemie uruchomione są cztery podejrzane procesy. A przynajmniej tyle ich widać dzięki zastosowaniu logonsessions.
NetstatPolecenie netstat podaje następujące informacje:
Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 764 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:8771 0.0.0.0:0 LISTENING 2020 TCP 0.0.0.0:16383 0.0.0.0:0 LISTENING 1320 TCP 127.0.0.1:1025 0.0.0.0:0 LISTENING 1592 TCP 172.16.0.41:2688 67.43.236.106:7000 ESTABLISHED 1844 UDP 0.0.0.0:445 : 4 UDP 0.0.0.0:500 : 468 UDP 0.0.0.0:1030 : 884 UDP 0.0.0.0:1032 : 884 UDP 0.0.0.0:1063 : 884 UDP 0.0.0.0:1064 : 884 UDP 0.0.0.0:1065 : 884 UDP 0.0.0.0:1066 : 884 UDP 0.0.0.0:4500 : 468 UDP 127.0.0.1:123 : 828 UDP 127.0.0.1:1900 : 920 UDP 172.16.0.41:69 : 1772 UDP 172.16.0.41:123 : 828 UDP 172.16.0.41:1900 : 920
Jak widać jest jedno połączenie nawiązane z adresem 67.43.236.106:7000. Jest to o tyle dziwne, że proces 1844 to (prawdziwy) proces explorer.exe, a przynajmniej tak się wydaje w tej chwili. Być może jakieś narzędzie "wstrzyknęło" coś do niego (na przykład własną bibliotekę) i maskując się jako prawdziwy explorer nawiązało połączenie z siecią. Temat do dalszej analizy. W każdym razie żałuję, że w trakcie zbierania danych o żywym systemie nie skorzystałem również z narzędzia listdlls, które już do skryptu sobie dodałem.
Pozostałe wylistowane porty znajdują się w stanie nasłuchu. Z grona podejrzanych można wykluczyć porty:
- TCP/135 (RPC),
- TCP/445 (SMB),
- TCP/1025 (usługa RPC) proces 1592 to alg.exe (składnik systemu),
- UDP/445 (SMB),
- UDP/123 (NTP),
- UDP/500 (IPSEC),
- UDP/4500 (IPSEC NAT-T),
Podejrzanie wygląda seria portów UDP otwartych przez proces 884. Jest to proces svchost, który hostować może w sobie inne usługi. Być może malware zainstalowało jakieś usługi, które działają w kontekście tego procesu. Z drugiej strony jednak na zdrowym systemie proces svchost również otwiera serię portów UDP, więc prawdopodobnie jest to ślepa uliczka. Podobnie prawdopodobnie będzie z portem UDP/1900, który teoretycznie może być otwarty przez malware, jednak najprawdopodobniej jest to usługa Universal Plug-and-Play.
Z całą pewnością podejrzane są natomiast porty:
- TCP/8771 otwarty przez pwpviex.exe,
- TCP/16383 otwarty przez ygcpzaf.exe,
- UDP/69 otwarty przez (fałszywy) iexplore.exe,
Kilka ciekawych rzeczy można dowiedzieć się również z drzewka procesów wygenerowanego przez pslist.
Name Pid Pri Thd Hnd VM WS Priv Idle 0 0 1 0 0 16 0 (...) explorer 1684 8 2 86 35100 4864 1836 iexplore 1772 8 2 98 33984 4560 1580 ygcpzaf 1320 8 2 38 18012 2892 2932 pwpveix 2020 8 2 39 18012 2900 2932 (...)
Jak widać procesy ygcpzaf i pwpveix zostały uruchomione przez proces iexplore. Procesy explorer oraz iexplore nie mają natomiast procesu "parent", co oznacza, że proces, które je uruchomił, zakończył już swój żywot.
Jak się uruchomi po restarcie?Dla malware ważne jest nie tylko to, by zainfekować komputer, ale również to, by przeżyć restart komputera, czyli po prostu - uruchomić się ponownie. Akurat ta część wcale nie musi być wykonywana na żywym systemie, ale tak jest po prostu wygodniej. Informacji może dostarczyć narzędzie autorunsc. Wyniki jego konsolowej wersji są jednak dość obfite, więc trzeba sobie jakoś ułatwić życie. Chodzi o znalezienie odwołań do plików, których nie było przed infekcją. Ponieważ to narzędzie nie było uruchamiane przy robieniu baseline systemu, trzeba poradzić sobie inaczej. Tutaj w celu szybkiej analizy wystarczyło następujące polecenie: for /f %i in ('grep MD5 autorunsc.txt') do @grep -i %i baseline.csv > nul || @echo %i Jego rezultatem jest lista hashy MD5, które występują w wyniku autoruns (autorunsc.txt), ale nie wystąpiły w pliku, w którym mam listę hashy plików czystego systemu (baseline.csv).
Rezultatem tego polecenia jest następująca lista:
- c1ab3a6d0df4667de52dac0c7b4a1595,
- c1ab3a6d0df4667de52dac0c7b4a1595 (tak, dwukrotnie),
- 847c928646ab5779fbaaa9738f04e108,
- b896384a176404ac1b1e4b0a3118d4f8,
- a63f4dade01007a69518b14275ca54b5,
Są to po kolei następujące wpisy:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell Explorer.exe Explorer.exe c:\windows\system32\explorer.exe c1ab3a6d0df4667de52dac0c7b4a1595 (MD5) 9199328ddf575aee42e0bfd07b39b8708da24412 (SHA-1) 53c61215e7195183b37bbcf01f8a0cb73d816b0ea5b32c2dd5f444ef915e7daa (SHA-256)
Ten wpis podmienia shell użytkownika (a nawet wszystkich) z właściwego %systemroot%\explorer.exe na %systemroot%\system32\explorer.exe. Oznacza to, że każdy logujący się interaktywnie użytkownik uruchomi ten proces.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run (...) Windows Explorer C:\WINDOWS\system32\explorer.exe c:\windows\system32\explorer.exe c1ab3a6d0df4667de52dac0c7b4a1595 (MD5) 9199328ddf575aee42e0bfd07b39b8708da24412 (SHA-1) 53c61215e7195183b37bbcf01f8a0cb73d816b0ea5b32c2dd5f444ef915e7daa (SHA-256) Microsoft Internet Explorer C:\WINDOWS\system32\iexplore.exe c:\windows\system32\iexplore.exe 847c928646ab5779fbaaa9738f04e108 (MD5) 92d748ec0079f63b6cc2b97eafbe13fb62711989 (SHA-1) df2bb1d34cdd86136410cecbd8738cea13c06ee42141fc6e08ea4c569047a9d4 (SHA-256) Advanced DHTML Enable C:\WINDOWS\system32\ygcpzaf.exe c:\windows\system32\ygcpzaf.exe b896384a176404ac1b1e4b0a3118d4f8 (MD5) 501415c70e0945bcb107caecf9ace129084e38c4 (SHA-1) fb9090eb8994f6f4b37a08222ece411d35ac0d1a9c20059b46b9d1ca0333284d (SHA-256)
W kluczu RUN znajduje się ponownie odwołanie o pliku %systemroot%\system32\explorer.exe, jak również do plików %systemroot%\system32\iexplore.exe i %systemroot%\system32\ygcpzaf.exe.
HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components (...) n/a c:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\ise32.exe c:\recycler\s-1-5-21-1482476501-1644491937-682003330-1013\ise32.exe a63f4dade01007a69518b14275ca54b5 (MD5) 029ff9287b8264a6a5ea130c84b05d446fdf4f20 (SHA-1) e095efd3b09c8d0f766fb655c6ea8632a0b62e1ad6064db2da25da4058a2797e (SHA-256) (...)
W kluczu Installed Components znajduje się natomiast odwołanie do pliku ise32.exe. O ile wpięcie się w shell i klucz RUN jest dość oczywiste, to muszę przyznać, że z wykorzystaniem Active Setup nie spotykałem się zbyt często, choć to pewnie raczej z tego powodu, że i malware na moich komputerach nie pojawiało się.
W powyższej liście jednak czegoś mi brakuje... Liczyłem na to, że malware zainstaluje jakiś BHO do Internet Explorera po to, by ułatwić sobie atak phishingowy. Ale może z czasem coś mi wyrośnie.
Różnice w systemie plikówTo też jest etap analizy, który wcale nie musi być wykonywany na żywym systemie, ale tym razem się tu załapie. Wystarczy porównać rezultaty polecenia dir /s /b c:\ wykonanego na czystym i zainfekowanym systemie. Wygodnym do tego narzędziem jest na przykład WinMerge. Tak naprawdę mogę wykonać dwa porównania:
- czystego systemu z systemem bezpośrednio po infekcji,
- systemu bezpośrednio po infekcji z systemem na której malware podziałał sobie chwilę (w tym pobrał nowe pliki),
Na razie jednak tylko ten pierwszy przypadek.
Nowe pliki:
- c:\RECYCLER\S-1-5-21-1482476501-1644491937-682003330-1013\ise32.exe,
- c:\WINDOWS\system32\gsxsrdx.exe,
- c:\WINDOWS\system32\hheyjo.exe,
- c:\WINDOWS\system32\pwpveix.exe,
- c:\WINDOWS\system32\qbqwov.exe,
- c:\WINDOWS\system32\wgwsafhn.exe,
Dodatkowo w c:\windows\prefetch pojawiły się (tylko najbardziej podejrzane):
- c:\WINDOWS\Prefetch\C1AB3A6D0DF4667DE52DAC0C7B4A1-36903391.pf (to mój robaczek, którego sam uruchomiłem),
- c:\WINDOWS\Prefetch\EXPLORER.EXE-0C648EA3.pf - to prawdopodobnie %systemroot%\system32\explorer.exe (w odróżnieniu od tego prawdziwego),
- c:\WINDOWS\Prefetch\FZDSV.EXE-21682E07.pf
- c:\WINDOWS\Prefetch\GSXSRDX.EXE-0A3F3987.pf
- c:\WINDOWS\Prefetch\HHEYJO.EXE-1168132C.pf
- c:\WINDOWS\Prefetch\IEXPLORE.EXE-07D1865D.pf - to prawdopodobnie %systemroot%\system32\iexplore.exe,
- c:\WINDOWS\Prefetch\PWPVEIX.EXE-12189FE9.pf
- c:\WINDOWS\Prefetch\QBQWOV.EXE-2A8C9D4C.pf
- c:\WINDOWS\Prefetch\WGWSAFHN.EXE-22DE95C8.pf
Jak widać lista uruchamianych plików jest dłuższa, niż lista tych nowych. Oznacza to, że część z tych plików została prawdopodobnie usunięta (lub inaczej ukryta). Będzie czego szukać.
A w następnym odcinku przyjrzę się dokładniej temu, co pliki w Prefetch mogą powiedzieć, a także poszukam zmian w innych plikach (czy istniejące pliki nie zostały zmodyfikowane), oraz w rejestrze.
Nazwy plikow wykonywalnych wygladaja na losowe. Sprawdzales czy w rejestrze wpisalo sobie zwierzatko cos, co przy restarcie kopiuje pliki ze zrodla sciagnietego do plikow ktore potem sa faktycznie wykonywane i wskazane w rejestrze?