Do you when approximately the first responder did his work? It looks like you've got some userinit.exe that started/stopped on 2013-05-26 and then another batch on 2013-06-01. If the first responder got there on 2013-06-01, then you know the weirdness wasn't anything caused by his actions since the issue existed at least as early as 2013-05-26. 

You scan the handles of running processes to see if any of them have open handles to the terminated processes (see [1]). That may help explain why they stuck around in the process list, but not why so many of the same processes started in the first place. 

IMO its not a bad capture and its probably not malicious. You might look in the event logs (in particular the application one) to see if there are any indications of the processes crashing and restarting. 

MHL

[1]. http://mnin.blogspot.com/2011/03/mis-leading-active-in.html

On Fri, Jun 7, 2013 at 12:58 PM, Glenn Edwards <hiddenillusion@gmail.com> wrote:

The tool the IH used in this instance was Cyber Marshal's wmr (http://cybermarshal.com/index.php/cyber-marshal-utilities/windows-memory-reader).

I've looked at dumps created by this tool in the past and this type of output/behavior wasn't observed.

On Fri, Jun 7, 2013 at 12:51 PM, Jesse Bowling <jessebowling@gmail.com> wrote:

I've had bad memory captures look a bit like this...Can you share what tool was used to collect the memory image?

Cheers,

Jesse

On Fri, Jun 7, 2013 at 12:04 PM, Glenn Edwards <hiddenillusion@gmail.com> wrote:

Background: The user logged off (I know, I know) of the system (WinXP) and the first responder logged back in under a different user and took the memory dump.

When running pslist against the memory dump there're 2,423 entries.  I'm seeing a lot of entries where the process starts and exits - sometimes in a row:

0x89b3f868 userinit.exe           3808    548      0 --------      0      0 2013-05-26 10:00:10 UTC+0000   2013-05-26 10:00:10 UTC+0000  

0x89b89ad0 userinit.exe           3156    548      0 --------      0      0 2013-05-26 10:00:28 UTC+0000   2013-05-26 10:00:28 UTC+0000  

0x89b2a868 userinit.exe           3672    548      0 --------      0      0 2013-05-26 11:30:11 UTC+0000   2013-05-26 11:30:11 UTC+0000  

0x89afc020 userinit.exe           3388    548      0 --------      0      0 2013-05-26 12:41:44 UTC+0000   2013-05-26 12:41:44 UTC+0000  

0x89b49da0 userinit.exe           1336    548      0 --------      0      0 2013-05-26 13:22:13 UTC+0000   2013-05-26 13:22:13 UTC+0000  

and sometimes more spread out:

0x89c1da98 java.exe               4536   1368      0 --------      0      0 2013-06-01 01:23:35 UTC+0000   2013-06-01 01:26:15 UTC+0000  

0x89141020 cscript.exe            8608   4536      0 --------      0      0 2013-06-01 01:24:12 UTC+0000   2013-06-01 01:24:14 UTC+0000  

0x89142da0 wmiprvse.exe           3152    832      0 --------      0      0 2013-06-01 01:24:12 UTC+0000   2013-06-01 01:25:42 UTC+0000  

0x89144ac0 minituner.exe          1120   1368      0 --------      0      0 2013-06-01 01:26:15 UTC+0000   2013-06-01 01:37:41 UTC+0000  

0x8934d520 java.exe               9148   1368      0 --------      0      0 2013-06-01 01:37:41 UTC+0000   2013-06-01 01:43:54 UTC+0000  

0x8934e020 cscript.exe            7620   9148      0 --------      0      0 2013-06-01 01:42:51 UTC+0000   2013-06-01 01:42:53 UTC+0000  

0x895423b8 wmiprvse.exe           3664    832      0 --------      0      0 2013-06-01 01:42:51 UTC+0000   2013-06-01 01:44:21 UTC+0000  

0x895ce8a0 minituner.exe          9940   1368      0 --------      0      0 2013-06-01 01:43:54 UTC+0000   2013-06-01 01:51:47 UTC+0000  

0x893a3838 java.exe               4572   1368      0 --------      0      0 2013-06-01 01:51:47 UTC+0000   2013-06-01 01:59:58 UTC+0000  

Example of top processes by overall count of occurrence:

$ cat pslist.txt | awk '{print $2}' | sort | uniq -c | sort -nr

    364 java.exe

    362 minituner.exe

    335 userinit.exe

    301 wmiprvse.exe

    219 cscript.exe

    192 verclsid.exe

     91 wuauclt.exe

     37 regsvr32.exe

     34 winlogon.exe

     34 csrss.exe

[snip]

I've never come across this before so I'm wondering if this could be attributed to the first responder not letting the system fully log them on prior to taking the memory dump and therefore there was a lot of still loading processes observed?

--

Glenn Edwards
@hiddenillusion

_______________________________________________
Vol-users mailing list
Vol-users@volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

--
Jesse Bowling

--

Glenn Edwards
@hiddenillusion

_______________________________________________
Vol-users mailing list
Vol-users@volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users