In short, no, there's not an easy way to determine which service dll in a shared svchost process allocated a particular memory region in the process, unless the dll saves a pointer to the allocated memory region in its .data section (or wherever the global variables are). Process memory regions aren't tagged like kernel pool allocations.
MHL On 5/19/16 8:42 AM, Laurent LF wrote: > Hi Michael, > > Thanks. Anyway, for the yara search, whether the IP conversion value is > stored as an integer or 4 consecutive uchar, we get the same search > pattern (at least with the current byte ordering). In fact I think I was > missing the --kernel option for yara, to look for structures in the > "System" process. I now get several occurences of the IP pattern yet all > with no owner ( Owner: (Unknown Kernel Memory) ) > > Also I am currently trying to figure out how I can know which service > run by a given svchost.exe instance is using a specific memory area for > which I know the VAD. > 1) Thanks to yara search, I find occurence of IP in a svchost process > and related memory address > 2) with vadinfo, I know the VAD of the memory section used by svchost > for above address > 3) with svcscan, I know the services run by the svchost instance. > 4) Is there a way to "easily" find which service uses the memory > described by the given VAD ? > > > As a side note, I have found interesting results in my case by looking > for remote mapped drives in memory with handles prefixed with > \Device\Mup as explained in "The Art of Memory Forensics" (I got it a > few days ago.). But in my case, among ~40 "\Device\Mup" handles, only > one is showing the pid of the svchost that runs the LanmanWorkstation > service, others are showing the process source of the connections. I was > thinking that more "\Device\Mup" would appear under the svchost process... > > > Thanks, > > Laurent LF > > > > > On 2016-05-17 16:13, Michael Ligh wrote: >> Yes, those are IN_ADDR: >> >> https://msdn.microsoft.com/en-us/library/windows/hardware/ff556972(v=vs.85).aspx >> >> >> So, not an integer - 4 UCHARs. You should be able to find the IN_ADDR >> structure with the proper yara rule in that case. >> >> MHL >> >> On 5/17/16 8:47 AM, Laurent LF wrote: >>> But for example netscan returns results based on structures found in >>> memory dump, so I think I should be able to find corresponding IP with >>> yarascan too ? Or am I wrong when I think that IPs are also stored as >>> Integer in those structures ? >>> >>> (sorry to be a pain) >>> >>> Thanks, >>> >>> Laurent >>> >>> >>> On 2016-05-17 15:12, Michael Ligh wrote: >>>> Hi Laurent, >>>> >>>> Not necessarily. You're assuming that everything once in memory >>>> stays in >>>> memory...which isn't the case. If you have an IP and you pass it to >>>> ws2_32.connect() and then free or overwrite the memory containing the >>>> IP...the connection stays up and running just fine. It could also be >>>> swapped to the page file. >>>> >>>> MHL >>>> >>>> On 5/17/16 5:14 AM, Laurent LF wrote: >>>>> 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 >>>>>>> > >>> _______________________________________________ >>> Vol-users mailing list >>> [email protected] >>> http://lists.volatilesystems.com/mailman/listinfo/vol-users >>> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Vol-users mailing list [email protected] http://lists.volatilesystems.com/mailman/listinfo/vol-users
