5. Were there any files that were able to be extracted from the initial process? How were these files extracted? (6pts)

Rozwiązania opierały się tutaj zwykle na zrzucie pamięci wirtualnej wybranych procesów i odzyskanie z nich plików PDF, na przykład przy użyciu narzędzia Foremost lub Scalpel. Ja do tego zadania podszedłem w nieco inny sposób, wspominałem o tym we wpisie Odczytywanie plików z filecache.

Fakt, wybrana przeze mnie metoda nie do końca może jest zgodna z pytaniem, szczególnie następującym jego fragmentem: from the initial process , ale jest ciekawsza :) Przy okazji można było nauczyć się czegoś o działaniu systemu od środka.

Odzyskanie pliku z filecache

Stosowane podejście opisałem już wcześniej we wspominanym wpisie, tutaj pokażę jego zastosowanie konkretnie w odniesieniu do zrzutu pamięci udostępnionego w ramach forensic challenge. Przypominam, że udostępniony zrzut jest w formacie raw i przed załadowaniem go do Windbg konieczna była konwersja do odpowiedniego formatu. Konwersja ta może być wykonana przy pomocy Volatility lub przy pomocy narzędzi z pakietu MoonSols Windows Memory Toolkit.

W pierwszym kroku poszukamy obiektu FILE_OBJECT, który będziemy odzyskiwać. Ponieważ atakowanym obiektem jest proces Acrobat Reader, właśnie od niego można zacząć:

16.kd> !process 0 0 (...) PROCESS 820618c8 SessionId: 0 Cid: 06d8 Peb: 7ffd6000 ParentCid: 0378 DirBase: 04040300 ObjectTable: e1ec4558 HandleCount: 184. Image: AcroRd32.exe

16.kd> .process /0 820618c8 Unknown option '0' Implicit process is now 820618c8

16.kd> !handle (...) 01d4: Object: 81dfadf0 GrantedAccess: 00120089 Entry: e110e3a8 Object: 81dfadf0 Type: (823eb040) File ObjectHeader: 81dfadd8 (old version) HandleCount: 1 PointerCount: 3 Directory Object: 00000000 Name: \DOCUME~1\ADMINI~1\LOCALS~1\Temp\plugtmp\PDF.php {HarddiskVolume1} (...)

16.kd> dt nt!FILEOBJECT 81dfadf0 +0x000 Type : 5 +0x002 Size : 112 +0x004 DeviceObject : 0x81dbf2d0 DEVICEOBJECT +0x008 Vpb : 0x823e5c50 _VPB +0x00c FsContext : 0xe10d2d90 +0x010 FsContext2 : 0xe1eb67d0 +0x014 SectionObjectPointer : 0x820cbeec SECTIONOBJECT_POINTERS +0x018 PrivateCacheMap : 0x820c1ca8 +0x01c FinalStatus : 0 +0x020 RelatedFileObject : (null) +0x024 LockOperation : 0 '' +0x025 DeletePending : 0 '' +0x026 ReadAccess : 0x1 '' +0x027 WriteAccess : 0 '' +0x028 DeleteAccess : 0 '' +0x029 SharedRead : 0x1 '' +0x02a SharedWrite : 0 '' +0x02b SharedDelete : 0 '' +0x02c Flags : 0x1c0042 +0x030 FileName : UNICODESTRING “\DOCUME~1\ADMINI~1\LOCALS~1\Temp\plugtmp\PDF.php” +0x038 CurrentByteOffset : LARGEINTEGER 0x4d13 +0x040 Waiters : 0 +0x044 Busy : 0 +0x048 LastLock : (null) +0x04c Lock : _KEVENT +0x05c Event : _KEVENT +0x06c CompletionContext : (null)

Ten sam rezultat można również uzyskać w nieco inny sposób:

16.kd> !filecache ***** Dump file cache****** Reading and sorting VACBs ... Removed 1746 nonactive VACBs, processing 292 active VACBs ... File Cache Information Current size 44764 kb Peak size 69144 kb 292 Control Areas Skipping view @ c1240000 – no VACB, but PTE is valid! Loading file cache database (100%25 of 130560 PTEs) SkippedPageTableReads = 130 File cache has 5974 valid pages

Usage Summary (in Kb): Control Valid Standby/Dirty Shared Locked FsContext Name (...) 82091008 20 0 0 0 e10d2d90 PDF.php (...)

16.kd> !ca 82091008

ControlArea @ 82091008 Segment e1713588 Flink 00000000 Blink 00000000 Section Ref 1 Pfn Ref 5 Mapped Views 1 User Ref 0 WaitForDel 0 Flush Count 0 File Object 81dfadf0 ModWriteCount 0 System Views 1

Flags (8008080) File WasPurged Accessed

File: \DOCUME~1\ADMINI~1\LOCALS~1\Temp\plugtmp\PDF.php

Segment @ e1713588 Type nt!MAPPEDFILE_SEGMENT not found.

Jak widać w ten sposób też znaleziony został FILE_OBJECT 81dfadf0.

Posiadając adres FILE_OBJECT można uzyskać dodatkowe informacje na jego temat:

16.kd> !fileobj 81dfadf0

\DOCUME~1\ADMINI~1\LOCALS~1\Temp\plugtmp\PDF.php

Device Object: 0x81dbf2d0 \Driver\Ftdisk Vpb: 0x823e5c50 Event signalled Access: Read SharedRead

Flags: 0x1c0042 Synchronous IO Cache Supported Handle Created Fast IO Read Random Access

FsContext: 0xe10d2d90 FsContext2: 0xe1eb67d0 Private Cache Map: 0x820c1ca8 CurrentByteOffset: 4d13 Cache Data: Section Object Pointers: 820cbeec Shared Cache Map: 820c1bd0 File Offset: 4d13 in VACB number 0 Vacb: 823b78c8 Your data is at: d2dc4d13

Interesuje nas informacja o adresie SHAREDCACHEMAP, w tym wypadku jest to 820c1bd0:

16.kd> dt nt!SHAREDCACHE_MAP 820c1bd0 +0x000 NodeTypeCode : 767 +0x002 NodeByteSize : 304 +0x004 OpenCount : 1 +0x008 FileSize : LARGEINTEGER 0x4d13 +0x010 BcbList : LISTENTRY [ 0x820c1be0 – 0x820c1be0 ] +0x018 SectionSize : LARGEINTEGER 0x40000 +0x020 ValidDataLength : LARGEINTEGER 0x4d13 +0x028 ValidDataGoal : LARGEINTEGER 0x4d13 +0x030 InitialVacbs : [4] 0x823b78c8 _VACB +0x040 Vacbs : 0x820c1c00 –> 0x823b78c8 _VACB +0x044 FileObject : 0x81dfadf0 FILEOBJECT +0x048 ActiveVacb : (null) +0x04c NeedToZero : (null) +0x050 ActivePage : 0 +0x054 NeedToZeroPage : 0 +0x058 ActiveVacbSpinLock : 0 +0x05c VacbActiveCount : 0 +0x060 DirtyPages : 0 +0x064 SharedCacheMapLinks : LISTENTRY [ 0x81c6706c – 0x81c6a404 ] +0x06c Flags : 0x1000 +0x070 Status : 0 +0x074 Mbcb : (null) +0x078 Section : 0xe1646158 +0x07c CreateEvent : (null) +0x080 WaitOnActiveCount : (null) +0x084 PagesToWrite : 0 +0x088 BeyondLastFlush : 0 +0x090 Callbacks : 0xf84300ac CACHEMANAGER_CALLBACKS +0x094 LazyWriteContext : 0xe10d2d90 +0x098 PrivateList : LISTENTRY [ 0x820c1cf4 – 0x820c1cf4 ] +0x0a0 LogHandle : (null) +0x0a4 FlushToLsnRoutine : (null) +0x0a8 DirtyPageThreshold : 0 +0x0ac LazyWritePassCount : 0 +0x0b0 UninitializeEvent : (null) +0x0b4 NeedToZeroVacb : (null) +0x0b8 BcbSpinLock : 0 +0x0bc Reserved : (null) +0x0c0 Event : _KEVENT +0x0d0 VacbPushLock : EXPUSH_LOCK +0x0d8 PrivateCacheMap : PRIVATECACHE_MAP

W tym miejscu pojawia się nieco magii. Sposób organizacji file cache zawiera różne optymalizacje, może pojawić się struktura “drzewiasta”. Tu na szczęście tak się nie dzieje, bo plik jest stosunkowo mały (patrz FileSize oraz SectionSize). W tym wypadku można popatrzeć na wskaźniki do VACB umieszczone w InitialVacbs:

16.kd> dp %25820c1bd0+0x030 820c1c00 823b78c8 00000000 00000000 00000000

Pozostaje tylko odczytać zawartość:

16.kd> dt nt!_VACB 823b78c8 +0x000 BaseAddress : 0xd2dc0000 +0x004 SharedCacheMap : 0x820c1bd0 SHAREDCACHE_MAP +0x008 Overlay : __unnamed +0x010 LruList : LISTENTRY [ 0x823b58f8 – 0x823b7140 ]

16.kd> db %250xd2dc0000 d2dc0000 25 57 4e 49 46 49 4c 53-4e 46 49 45 4f 57 4e 53 %25WNIFILSNFIEOWNS d2dc0010 44 46 0d 0a 25 44 4b 4b-4b 53 44 46 4e 49 45 0d DF..%25DKKKSDFNIE. d2dc0020 0a 25 50 44 46 2d 31 2e-33 0d 0a 25 4d 4d 57 49 .%25PDF-1.3..%25MMWI d2dc0030 45 4e 4f 46 0d 0a 25 57-4e 49 46 49 4c 53 4e 46 ENOF..%25WNIFILSNF d2dc0040 49 45 4f 57 4e 53 44 46-0d 0a 31 30 35 34 20 30 IEOWNSDF..1054 0 d2dc0050 20 6f 62 6a 0d 0a 3c 3c-2f 4c 65 6e 67 74 68 20 obj..<</Length d2dc0060 30 30 30 30 2f 46 69 6c-74 65 72 20 5b 2f 46 23 0000/Filter [/F# d2dc0070 36 63 23 36 31 23 37 34-65 23 34 34 65 23 36 33 6c#61#74e#44e#63

I jeszcze końcówka pliku uwzględniając jego rozmiar:

16.kd> db %250xd2dc4d13 L-100 d2dc4c13 30 20 52 3e 3e 0d 0a 65-6e 64 6f 62 6a 0d 0a 37 0 R>>..endobj..7 d2dc4c23 38 37 20 30 20 6f 62 6a-0d 0a 3c 3c 2f 43 6f 75 87 0 obj..<> d2dc4c53 0d 0a 65 6e 64 6f 62 6a-0d 0a 31 31 20 30 20 6f ..endobj..11 0 o d2dc4c63 62 6a 0d 0a 3c 3c 2f 53-2f 4a 61 76 61 53 63 72 bj..< d2dc4c83 3e 0d 0a 65 6e 64 6f 62-6a 0d 0a 31 38 34 37 20 >..endobj..1847 d2dc4c93 30 20 6f 62 6a 0d 0a 3c-3c 2f 50 61 72 65 6e 74 0 obj..<>>>..endobj. d2dc4ce3 0a 78 72 65 66 0d 0a 74-72 61 69 6c 65 72 0d 0a .xref..trailer.. d2dc4cf3 3c 3c 2f 52 6f 6f 74 20-31 31 32 20 30 20 52 3e < d2dc4d03 3e 0d 0a 64 4c 4e 57 45-49 4f 46 39 33 66 30 6e >..dLNWEIOF93f0n

Jak widać – w coś trafiłem, a poszukiwane dane znajdują się pomiędzy 0xd2dc0000 a 0xd2dc4d13, plik można odzyskać korzystając z .writemem. Rezultaty Virustotal na odzyskanym pliku można znaleźć tu: http://www.virustotal.com/analisis/551147a39bc439f46421a994fdbe6c5bafed90bf3b79121722d95bfa1ea435a1-1273748929.

Warto zwrócić uwagę, że pliki odzyskane przez uczestników wyzwania nieco różniły się od pliku, który został odzyskany przeze mnie. Między innymi różniły się wielkością, być może carver jako plik potraktował zbyt wiele. W każdym razie również w odzyskanym przeze mnie pliku można znaleźć “interesujący” fragment obfuskowango kodu, dokładnie taki sam, jak został przedstawiony w nagrodzonych rozwiązaniach. Warto też zwrócić uwagę na jedno z rozwiązań (autor: Carl Pulley), w którym plik został odzyskany w inny sposób i jest identyczny z tym odzyskanym przeze mnie, patrz http://www.virustotal.com/analisis/551147a39bc439f46421a994fdbe6c5bafed90bf3b79121722d95bfa1ea435a1-1269936720.

Kto odzyskał bardziej prawdziwy plik wykorzystany do ataku? Wydaje mi się, że mój sposób odzyskania pliku dość dobrze się broni, jeśli uwzględni się sposób działania systemu Windows, ale sam temat jest bardzo interesujący. Może trzeba będzie poświęcić mu więcej czasu w przyszłości.

Oryginał tego wpisu dostępny jest pod adresem Rozwiązanie wyzwania: Forensic Challenge 2010 – Banking Troubles

Autor: Paweł Goleń