Finding Network Socket Activity in Pools

First we need to develop a signature. This is the most difficult part of the analysis. We're interested in TCP/IP address objects, so tcpip.sys might be a good starting point. Some research finally leads to the function 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

What can be learned from the code?

• we will have to look for pool allocations tagged with 'TCPA'; note it's written right to left above because the tag is stored as a 32-bit integer on a little-endian machine


• the allocations will always consist of 368 bytes; 360 bytes for the payload as requested and 8 bytes for the pool header


• the allocations will reside in the non-paged pool

This should suffice to locate the needed data in a memory dump. The rest of the code quoted above then will help to interpret the data found. Please note that all offsets given depend on the Windows version. The 'TCPA' tag however appears to be constant.

In order to test the procedure I ran an instance of Microsoft Windows XP Service Pack 2 in VMware 5.5.1. I launched a netcat listener on port 666 but did not connect to it. Then I terminated the listener and suspended the session. Finally I searched the VMEM file (which contains the emulated physical memory) for pool allocations in general and for allocations tagged with 'TCPA' in particular.

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

You'll find the socket opened by netcat right in the middle of the list. The allocation holding its data was already marked as free. But fortunately it was not reused yet. Please compare the list to the situation as shown by PTfinder. PID and start time are matching.

In a similiar way it's also possible to reveal TCP connections:

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

Here you see Windows Update 'phoning home' to Microsoft immediately after the system came up (PID 884 is an instance of svchost.exe). Too bad connection objects do not contain time stamps like the address objects shown before.