Paweł Goleń, blog

Pliki, których szukam:

• C:\Documents and Settings\Administrator\Desktop\c1ab3a6d0df4667de52dac0c7b4a1595.exe
• C:\WINDOWS\system32\fzdsv.exe
• C:\WINDOWS\system32\hvhje.bat
• C:\Documents and Settings\Administrator\Desktop\yhxdrg.bat

Po pierwsze wykonałem obraz dysku w zainfekowanym systemie. Zrobiłem to przy pomocy magicznego narzędzia o mitycznej nazwie dd. Podstawowym narzędziem (a właściwie zestawem narzędzi), które wykorzystuję przy analizie jest Sleuthkit. Można się też wspomagać do pewnego stopnia narzędziami FTK Imager lub ProDiscover Basic.

Informację o systemie plików uzyskuje się przy pomocy narzędzia fsstat:

FILE SYSTEM INFORMATION 
-------------------------------------------- 
File System Type: NTFS 
Volume Serial Number: 5850105B50104264 
OEM Name: NTFS 
Version: Windows XP

METADATA INFORMATION 
-------------------------------------------- 
First Cluster of MFT: 348762 
First Cluster of MFT Mirror: 523144 
Size of MFT Entries: 1024 bytes 
Size of Index Records: 4096 bytes Range: 0 - 8591 
Root Directory: 5

CONTENT INFORMATION 
-------------------------------------------- 
Sector Size: 512 
Cluster Size: 2048 
Total Cluster Range: 0 - 1046287 
Total Sector Range: 0 - 4185151 
(...) 

Z tych informacji najważniejsze są:

• System plików: NTFS,
• Informacja o rozmiarze klastra: 2048,
• Informacja o liczbie rekordów MFT: 8591 (no, 8592, bo 0 to też prawidłowy rekord),

Aby uzyskać informację o zaalokowanych rekordach, można wykonać polecenie: ils -a image.dd | grep "|a|" | wc -l Wynikiem tego polecenia jest liczba zaalokowanych rekordów w MFT. Wynikiem to 8432.

Listę usuniętych plików (czyli rekordy w MFT, które są, ale mają status Not Allocated File można uzyskać poleceniem ils -m image.dd. Niestety, na podanej liście nie znalazł się żaden z interesujących mnie plików. Oznacza to prawdopobnie, że:

• rekordy MFT wykorzystywane przez te pliki po ich usunięciu zostały wykorzystane ponownie,
• prawdopodobnie nie uda mi się odzyskać plików *.bat (prawdopodobnie całe mieściły się w MFT),
• same dane należące do tych plików być może są gdzieś na dysku...

Puste miejsce i slack space W związku z tym wyodrębniłem puste (niezaalokowane) miejsce, oraz tak zwany slack space, czyli te klastry, które zawierają już dane nowego pliku, ale poprzednia zawartość nie została całkiem nadpisana. Na przykład jeśli plik ma rozmiar 1024 bajtów, to jest to za dużo, by zmieścił się w całości w MFT, więc dane są zapisywane w oddzielnym klastrze. Klaster ma jednak aż 2048 bajtów, a więc pozostaje niezapisanych 1024 bajtów. W praktyce te niezapisane bajty mogą zawierać dane z pliku, który zajmował ten klaster wcześniej. Do wyodrębnienia tych obszarów służy polecenie dls.

Co dalej? Jestem w tej dobrej sytuacji, że wiem, czego szukam. A szukam dwóch plików *.exe i dwóch plików *.bat. W obu przypadkach można próbować wyszukać pewnych charakterystycznych elementów.

W przypadku pliku EXE jest to na pewno jego nagłówek. Należy po prostu wyszukać frazy MZ (zresztą bardzo fajny artykuł: What's the difference between the COM and EXE extensions). W slack space tej sygnatury nie ma, natomiast w obszarze "wolnym" wystąpiła ona kilka razy:

42085218:8MZ 
279671650:8MZ 
300892253:R.jgaMZA8n^ 
300968055:YMZ_[xFk- 
300968241:R_[MZ4

Tutaj przydaje się informacja o wielkości klastra, aby znaleźć miejsce na dysku (a właściwie w jego obrazie), należy podzielić offset przez rozmiar klastra, a następnie użyć polecenia dcalc. Numery klastrów są następujące:

• 219224,
• 568506,
• 636791,
• 636828 (2 razy),

Po sprawdzeniu tych klastrów jednak nie znalazłem oczekiwanych plików *.exe. Dziwne... Druga fraza, której można szukać w pliku tego typu to "This program cannot be run in DOS mode". Tutaj mam więcej szczęścia

2932813:!This program cannot be run in DOS mode. 
22067277:!This program cannot be run in DOS mode. 
52160589:!This program cannot be run in DOS mode.

Od razu przeliczając na sektory:

• 88067,
• 114206,
• 278061,

Cóż, zupełnie inne fragmenty, niż sugerowało to wyszukanie sygnatury, czyli frazy MZ. Sprawdziłem, przepuszczenie pliku wykonywalnego przez strings (implementacja z Sysinternals) nie znajduje frazy MZ, nawet wiem dlaczego:

Mój błąd, nie pomyślałem, że 2 litery to trochę za krótka sygnatura, i w przypadku nawet losowych danych występuje dość często. Jeśli ktoś ma wątpliwości, to proszę bardzo, prosty eksperyment:

$ cat /dev/arandom | strings -o | grep MZ 
3362 iMZ7\n 
226262 MZWDN) 
654316 y8MZ (...)

Po sprawdzeniu, rzeczywiście znajdują się tam (fragmenty) plików wykonywalnych. Dla pewności sprawdziłem jeszcze za pomocą narzędzia ifind, czy na pewno w MFT nie ma informacji na temat tych klastrów. No niestety, na pewno nie ma... Pozostaje mi określić co to za pliki po ich zawartości.

W przypadku 88067 niestety zawartość niewiele mówi na temat pliku, przynajmniej na pierwszy rzut oka. Lepiej jest w przypadku pliku 114206:

(...) 
416 00000000 00000000 00000000 00000000 .... .... .... .... 
432 00000000 00000000 2e706163 6b656400 .... .... .pac ked. 
448 00100200 00100000 00000000 00040000 .... .... .... .... 
464 00000000 00000000 00000000 200000e0 .... .... .... ... 
480 2e524c50 61636b00 00c00000 00200200 .RLP ack. .... . .. 
496 18bb0000 00040000 00000000 00000000 .... .... .... .... 
(...)

Jak widać pojawiają się dwa słowa kluczowe .packed oraz .RLPack. Ten plik to na 99% jeden z zagubionych.

Plik 278061 można raczej wykluczyć:

5792 4a001100 01004600 69006c00 65004400 J... ..F. i.l. e.D. 
5808 65007300 63007200 69007000 74006900 e.s. c.r. i.p. t.i. 
5824 6f006e00 00000000 50007200 6f006300 o.n. .... P.r. o.c. 
5840 65007300 73002000 45007800 70006c00 e.s. s. . E.x. p.l. 
5856 6f007200 65007200 00000000 2a000500 o.r. e.r. .... *... 
5872 01004600 69006c00 65005600 65007200 ..F. i.l. e.V. e.r. 
5888 73006900 6f006e00 00000000 39002e00 s.i. o.n. .... 9... 
5904 33003000 00000000 38000c00 01004900 3.0. .... 8... ..I. 
5920 6e007400 65007200 6e006100 6c004e00 n.t. e.r. n.a. l.N. 
5936 61006d00 65000000 70007200 6f006300 a.m. e... p.r. o.c. 
5952 65007800 70002e00 73007900 73000000 e.x. p... s.y. s... 
5968 72002700 01004c00 65006700 61006c00 r.'. ..L. e.g. a.l. 
5984 43006f00 70007900 72006900 67006800 C.o. p.y. r.i. g.h. 
6000 74000000 43006f00 70007900 72006900 t... C.o. p.y. r.i. 
6016 67006800 74002000 28004300 29002000 g.h. t. . (.C. ). . 
6032 4d002e00 20005200 75007300 73006900 M... .R. u.s. s.i. 
6048 6e006f00 76006900 63006800 20003100 n.o. v.i. c.h. .1. 
6064 39003900 36002d00 32003000 30003500 9.9. 6.-. 2.0. 0.5. 
6080 00000000 40000c00 01004f00 72006900 .... @... ..O. r.i. 
6096 67006900 6e006100 6c004600 69006c00 g.i. n.a. l.F. i.l. 
6112 65006e00 61006d00 65000000 70007200 e.n. a.m. e... p.r. 
6128 6f006300 65007800 70002e00 53007900 o.c. e.x. p... S.y. 
6144 73000000 42001100 01005000 72006f00 s... B... ..P. r.o. 
6160 64007500 63007400 4e006100 6d006500 d.u. c.t. N.a. m.e. 
6176 00000000 50007200 6f006300 65007300 .... P.r. o.c. e.s. 
6192 73002000 45007800 70006c00 6f007200 s. . E.x. p.l. o.r. 
6208 65007200 00000000 2e000500 01005000 e.r. .... .... ..P.

Jak widać z zawartego w nim opisie wynika, że jest to ProcessExplorer, a konkretnie to plik procexp.sys.

W takim razie pozostaje tylko odzyskać pliki 88067 i 114206. Jak to zrobić? Tutaj przyznam się, że dla wygody posłużyłem się FTK Imager, choć jego działanie mogę dokładnie zasymulować w tym zakresie przy pomocy Sleuthkit. Po prostu zrzucam do pliku nieużywany obszar dysku, który się zaczyna w klastrze o numerze zidentyfikowanym przeze mnie, a kończy, na pierwszym używanym. Jest to (spore) uproszczenie, ale w tym wypadku działa.

W pierwszym wypadku okazało się, że plik wcale nie jest podejrzany, lecz jest to plik Procmon.sys, czyli składnik używanego przeze mnie narzędzia Procmon.

W drugim wypadku miałem więcej szczęścia, co potwierdził zresztą VirusTotal i ClamAV:

C:\VirtualPC\Malware\disk_image\exe\114206: Worm.Kolab-173 FOUND 
----------- SCAN SUMMARY ----------- 
Known viruses: 293870 
Engine version: 0.93 
Scanned directories: 0 
Scanned files: 1 
Infected files: 1

Data scanned: 0.07 MB Time: 7.094 sec (0 m 7 s) 
-------------------------------------- 
Completed 
-------------------------------------- 

Co z drugim plikiem *.exe? Obawiam się, że jego odzyskanie może być trudne (przynajmniej dla mnie). Ale to nie ma większego znaczenia, bo akurat ten drugi zaginiony plik jest znany: c1ab3a6d0df4667de52dac0c7b4a1595.exe. A przynajmniej tak mi się wydaje, skoro MD5 pliku "odzyskanego" to 9681cbfa564c0c73434a6a743927e8bc.

Teraz pora na pliki *.bat. Tutaj nie można mówić o jakimś nagłówku, którego można się spodziewać. Zamiast tego można się spodziewać, że zostaną wykorzystane w nim jakieś polecenia systemowe. Niestety, jest to nikłe uproszczenie, bo polecenia te są również dość często występującymi słowami. W praktyce przejrzeć trzeba było wszystkie znalezione stringi... Nie znalazłem nic, co mogło wyglądać jak plik *.bat. Co prawda mogłem go po prostu przeoczyć, bardziej jednak spodziewałbym się tego, że zawartość tych dwóch plików została po prostu nadpisana. Dla pewności przeglądnąłem jeszcze zawartość $MFT, niestety również bez sukcesów.

Znalazłem za to coś innego. Zarówno w slack space, jak i w nieużywanym obszarze dysku znalazłem frazę 127.0.0.1. Konkretnie jest to część tego, co zostało zapisane do pliku hosts.

...i to by było tyle w tym mało interesującym odcinku... Następny, prawdopodobnie już ostatni odcinek będzie zawierał analizę logu Procmon.