Thanks Michael,
What I don't understand is that yarascan on the "IP to integer" value on
the full mem dump gives a result in the svchost process only and not
anywhere else. I should have at least two occurences, one in the svchost
process and one other in the System process, right ?
Thanks,
Laurent
On 2016-05-12 23:18, Michael Ligh wrote:
I can't speak to whether its
"normal" but its not surprising. The System
process is the default home for threads that start in kernel mode. Thus
any kernel driver using the winsock APIs for networking will make it
appear as if the System process is responsible. Now combine that with a
DLL that's implementing a particular service (and running inside
svchost.exe process) who wants to communicate with its corresponding
driver...it could send an IOCTL and say "go connect to this x.x.x.x IP
address." In that case you could easily end up with a reference to the
IP in svchost.exe.
MHL
On 5/10/16 2:34 PM, Laurent LF wrote:
> Hi,
>
> I have progressed a bit on this.
> I was first limiting my IP addresses searches on the process returned by
> "netscan", which was "System" with pid=4. As I was convinced I
should
> have got some results within "System", I supposed I was wrong with the
> syntax or the IP representation and made several other tries (IP as
> string, little indian ordering as suggested by Andrew,...), still with
> pid=4. I also made a few tries on the whole memory dump but with no
> luck. It looks like I was doing something wrong because today I made
> some tries again on full memory dump and finally found the IPs (Big
> Indian ordering) in ... a "svchost" process.
>
> I still need to go deeper in the analysis (as far as my little knowledge
> will allow me to go :-) ) but is it normal behavior to have netscan
> reporting some connections linked with "System" when IP search with
> yarascan on given IPs returns only a "svchost" process ?
> Also, I was expecting to find references to the IPs in several memory
> locations but only one occurence in this case, in the given svchost
> process...
>
> Thanks,
> Laurent
>
>
> Le 10/05/2016 17:14, Michael Ligh a écrit :
>> Also note yarascan only accesses available pages. The IP could be in a
>> page that's swapped to the pagefile or in a page that's been
>> freed/deallocated and is no longer referenced from any page
>> table(s). In
>> the later case, you could find it by extracting strings from the memory
>> dump or by scanning with yara signatures across the memory dump file
>> (i.e. not caring about virtual address spaces)...however if you find it
>> in either of two methods, there's no way to trace the page back to its
>> owner.
>>
>> MHL
>>
>> On 5/10/16 7:56 AM, Andrew Case wrote:
>>> Hey,
>>>
>>> Did you try the IP hex value in reverse? It is likely that the IP
>>> address is stored as little endian in memory.
>>>
>>> Thanks,
>>> Andrew (@attrc)
>>>
>>> On 05/10/2016 05:15 AM, tech(a)nisteo.fr wrote:
>>>> Hello,
>>>>
>>>> I am starting to play with Volatility (2.5) and I am currently
>>>> working
>>>> on a Win2008R2 image (memory dump with winpmem). I would like to
>>>> understand what is causing some network connections initiated by the
>>>> "System" process.
>>>> netscan shows those connections and I would like to be able to find
>>>> references to the IP addresses in the memory dump. I have tried
>>>> "yarascan -Y" plugin with the IP string, with the IP to integer
value
>>>> (converted to Hex) but no luck finding IPs that , however, I can
>>>> see in
>>>> the netscan result...
>>>> Either I am wrong with the yarascan syntax or there is something I
>>>> don't
>>>> know regarding how Win2008 stores IP...
>>>>
>>>> Any hints ?
>>>>
>>>> Thanks,
>>>>
>>>> Laurent
>>>> _______________________________________________
>>>> Vol-users mailing list
>>>> Vol-users(a)volatilityfoundation.org
>>>>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>
>>> _______________________________________________
>>> Vol-users mailing list
>>> Vol-users(a)volatilityfoundation.org
>>>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>
>
>