I've got some questions regarding my IMF paper. So I decided to provide a use-case for an analysis based on pool allocations. This will reveal TCP/IP sockets in listening state and also network connections.
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 -> 22.214.171.124:80, PID=884 Connection: 192.168.186.128:1037 -> 126.96.36.199:80, PID=884 Connection: 192.168.186.128:1038 -> 188.8.131.52: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.