Netzwerkaktivität in Pools finden

Die erste Aufgabe besteht darin, eine geeignete Signatur zu finden. Dies ist in der Regel auch der schwierigste Teil der Untersuchung. In diesem Beispiel sind TCP/IP Address Objekte das Ziel, der Treiber tcpip.sys erscheint deshalb als ein guter Ausgangspunkt für die weitere Untersuchung. Die nähere Betrachtung führt dann auf die Funktion tcpip!TdiOpenAddress:

.text:0001CD5D                 push    NormalPagePriority
.text:0001CD5F                 push    'APCT'          ; Tag
.text:0001CD64                 push    360             ; NumberOfBytes
.text:0001CD69                 push    NonPagedPool    
.text:0001CD6B                 call    ds:__imp__ExAllocatePoolWithTagPriority@16
...
.text:0001CF4D                 mov     eax, [ebp+var_LocalAddress]
.text:0001CF50                 mov     [esi+44], eax
.text:0001CF53                 mov     al, byte ptr [ebp+arg_Protocol]
.text:0001CF56                 mov     [esi+50], al
...
.text:0001CF5C                 mov     [esi+48], di    ; LocalPort
...
.text:0001CF76                 call    _PsGetCurrentProcessId@0
.text:0001CF7B                 mov     [esi+328], eax
.text:0001CF81                 lea     eax, [esi+344]
.text:0001CF87                 push    eax             ; CurrentTime
.text:0001CF88                 call    ds:__imp__KeQuerySystemTime@4

Was kann man aus diesem Codeauszug ableiten?

• die gesuchten Allokationen sind mit der Zeichenfolge "TCPA" markiert; bitte beachten Sie, dass die Markierung im Programmcode von rechts nach links geschrieben wird, weil sie als 32-Bit-Zahl im Little-Endian-Format dargestellt wird.


• die Allokation umfasst immer 368 Bytes; 360 Bytes für die Nutzdaten und 8 Bytes für den Pool Header


• die Allokation befindet sich im non-paged Pool.

Diese Bedingungen genügen um die Daten in einem Speicherabbild zu lokalisieren. Der restliche oben abgebildete Code ermöglicht dann, die gefundenen Daten zu interpretieren. Bitte beachten Sie, dass alle genannten Offsets von der jeweiligen Windows-Version abhängen. Lediglich die Markierung "TCPA" scheint sich nicht zu ändern.

Um das Verfahren zu testen, habe ich Microsoft Windows XP Service Pack 2 in VMware 5.5.1 ausgeführt. Ich startete Netcat und lies es auf Port 666/tcp auf eine Verbindung warten. Allerdings baute ich keine Verbindung auf, sondern beendete Netcat nach kurzer Zeit wieder. Dann fror ich die VMware-Sitzung ein. Schließlich durchsuchte ich die von VMware erstellte VMEM-Datei (sie enthält den emulierten physischen Speicher) nach Allokationen und insbesondere natürlich nach solchen, die mit "TCPA" markiert sind.

Address: 192.168.186.128:138/UDP, PID=4, 2006-07-17 22:08:47
Address: 0.0.0.0:135/TCP, PID=800, 2006-07-17 22:08:40
Address: 0.0.0.0:0/IGMP, PID=884, 2006-07-17 22:08:49
Address: 0.0.0.0:0/GRE, PID=4, 2006-07-17 22:08:51
Address: 0.0.0.0:1029/UDP, PID=948, 2006-07-17 22:09:46
Address: 127.0.0.1:1025/TCP, PID=1508, 2006-07-17 22:08:51
Address: 0.0.0.0:666/TCP, PID=1448, 2006-07-17 22:11:15 (defunct)
Address: 192.168.186.128:139/TCP, PID=4, 2006-07-17 22:08:47
Address: 192.168.186.128:137/UDP, PID=4, 2006-07-17 22:08:47
Address: 127.0.0.1:1028/UDP, PID=884, 2006-07-17 22:08:54
Address: 0.0.0.0:1026/TCP, PID=4, 2006-07-17 22:08:51
Address: 0.0.0.0:445/TCP, PID=4, 2006-07-17 22:08:27
Address: 0.0.0.0:445/UDP, PID=4, 2006-07-17 22:08:27
Address: 127.0.0.1:1027/UDP, PID=884, 2006-07-17 22:08:54

In der Mitte der Liste sehen Sie den von Netcat geöffneten Socket. Die entsprechende Allokation war bereits freigegeben, glücklicherweise aber noch nicht wieder genutzt worden. Bitte vergleichen Sie die Liste jetzt mit von PTfinder dargestellten Prozesshierarchie. PID und Startzeit stimmen überein.

In ähnlicher Weise lassen sich auch TCP-Verbindungen nachweisen:

Connection: 192.168.186.128:1039 -> 64.4.21.93:80, PID=884
Connection: 192.168.186.128:1037 -> 213.253.9.70:80, PID=884
Connection: 192.168.186.128:1038 -> 213.253.9.70:80, PID=884

Hier sehen Sie übrigens, wie Windows Update kurz nach dem Start des Systems "nach Hause telefoniert" (PID 884 ist eine Instanz von svchost.exe). Bedauerlicherweise enthalten die Connection-Objekte im Gegensatz zu den oben gezeigten Address-Objekten keine Zeitmarken.