[Vol-users] Mucho processes

Michael Hale Ligh michael.hale at gmail.com
Fri Jun 7 13:03:21 CDT 2013


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 at 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 at 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 at 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 at volatilityfoundation.org
>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>
>>>
>>
>>
>> --
>> Jesse Bowling
>>
>>
>
>
> --
> Glenn Edwards
> @hiddenillusion
>
> _______________________________________________
> Vol-users mailing list
> Vol-users at volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.volatilityfoundation.org/pipermail/vol-users/attachments/20130607/5e23bf93/attachment.html


More information about the Vol-users mailing list