I found a bug in process explorer tool. well, not a bug, a feature process explorer tries to determine start addresses of threads, but it not always works. get the file va_thread.c (attached), compile it, run and see the bug yourself. process explorer correctly determines the start addresses of the two first threads, but stumbles over third, created in the malware's manner (it allocates memory on heap, copies malicious code and calls Create[Remote]Thread). process explorer says: the start address of the third thread is: KERNEL32.DLL+B700h, but it's definitely wrong! actual start address has to look like 00520000h or somewhere around it. I don't know how process explorer determines the start addresses of threads, but I found very simply and quite reliable way to do that. I noticed that the start address of the thread lies on the bottom of the user stack in the second or third dword, followed by lpParameter. this works under Windows 2000 and Windows Server 2003, I didn't check out Windows XP yet, but I hope, it will be the same. I wrote quick and dirty utility proclist.c correctly determines start addresses in the most cases and discovers malware, which allocating memory with VirtualAllocEx to "inject" into process, or loads malicious DLL via creating remote thread, passing address of the LoadLibraryA/W and places name of malicious library in lpParameter. in the first case, start address of the malicious thread belongs to MEM_PRIVATE area (instead of MEM_IMAGE like normal exe/dll does), and in the second case start address matches LoadLibraryA/W. I checked this method on my malware collection and got good result. I hope, you will find this information useful with best regards, kris kaspersky
