Re: [Vol-users] Sample error or real module? (and other questions)

Thanks Andrew. That confirms it's a raw file. <volatility.plugins.addrspaces.standard.FileAddressSpace object at 0xafd2dcc> I corrected the yarascan commandline, but there were no hits for the "Copyright (c) 1992-2004" string. So I switched to a more specific string in the output, "licensed by Dinkumware," and got the following: Owner: (Unknown Kernel Memory) 0xf8a0051f40ae 6c 69 63 65 6e 73 65 64 20 62 79 20 44 69 6e 6b licensed.by.Dink 0xf8a0051f40be 75 6d 77 61 72 65 00 00 00 00 00 00 00 00 00 00 umware.......... 0xf8a0051f40ce 00 00 04 01 09 03 53 61 46 41 00 00 00 00 00 00 ......SaFA...... 0xf8a0051f40de 00 00 78 e3 2c 03 80 f8 ff ff 01 00 00 00 00 00 ..x.,........... 0xf8a0051f40ee 00 00 c5 db 02 00 00 00 02 00 20 c8 22 00 a0 f8 ............"... 0xf8a0051f40fe ff ff 70 41 1f 05 a0 f8 ff ff 20 c8 22 00 a0 f8 ..pA........"... 0xf8a0051f410e ff ff c5 db 02 00 00 00 02 00 01 08 20 00 00 00 ................ 0xf8a0051f411e 00 00 d8 6a ac 9b 02 00 00 00 00 00 00 00 00 00 ...j............ 0xf8a0051f412e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xf8a0051f413e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0xf8a0051f414e 00 00 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 ................ 0xf8a0051f415e 00 00 09 01 09 03 53 61 46 41 00 00 00 00 00 00 ......SaFA...... 0xf8a0051f416e 00 00 78 e3 2c 03 80 f8 ff ff 01 00 00 00 00 00 ..x.,........... 0xf8a0051f417e 00 00 dc c1 02 00 00 00 05 00 20 c8 22 00 a0 f8 ............"... 0xf8a0051f418e ff ff 00 42 1f 05 a0 f8 ff ff 20 c8 22 00 a0 f8 ...B........"... 0xf8a0051f419e ff ff dc c1 02 00 00 00 05 00 01 08 20 00 00 00 ................ And 3 more similar hits: Owner: (Unknown Kernel Memory) 0xf8a0051f50ae 6c 69 63 65 6e 73 65 64 20 62 79 20 44 69 6e 6b licensed.by.Dink Owner: (Unknown Kernel Memory) 0xf8a0051f40ae 6c 69 63 65 6e 73 65 64 20 62 79 20 44 69 6e 6b licensed.by.Dink Owner: (Unknown Kernel Memory) 0xf8a0051f50ae 6c 69 63 65 6e 73 65 64 20 62 79 20 44 69 6e 6b licensed.by.Dink Then, if I go into volshell, I can find this, as expected: 0xf8a0051f40ae 6c 69 63 65 6e 73 65 64 20 62 79 20 44 69 6e 6b licensed.by.Dink 0xf8a0051f40be 75 6d 77 61 72 65 00 00 00 00 00 00 00 00 00 00 umware.......... 0xf8a0051f40ce 00 00 04 01 09 03 53 61 46 41 00 00 00 00 00 00 ......SaFA...... 0xf8a0051f40de 00 00 78 e3 2c 03 80 f8 ff ff 01 00 00 00 00 00 ..x.,........... 0xf8a0051f40ee 00 00 c5 db 02 00 00 00 02 00 20 c8 22 00 a0 f8 ............"... 0xf8a0051f40fe ff ff 70 41 1f 05 a0 f8 ff ff 20 c8 22 00 a0 f8 ..pA........"... 0xf8a0051f410e ff ff c5 db 02 00 00 00 02 00 01 08 20 00 00 00 ................ 0xf8a0051f411e 00 00 d8 6a ac 9b 02 00 00 00 00 00 00 00 00 00 ...j............ So it seems there was something awry with the 'strings' input or output, perhaps? None of the addresses provided by 'strings' seem to match up with what 'yarascan' found. Here are the addresses provided by 'strings': 4397692928 [kernel:f9805ba44800] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 4401204576 [kernel:f8a021c19d60] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 4410548688 [kernel:f9803f62c1d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 4563104208 [kernel:f9806300e1d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 4727559968 [kernel:f9804181a720] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 4738933200 [kernel:f9808a5001d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 4740919640 [kernel:fa8015ea9158] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 4952543696 [kernel:fa8015f731d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 5138492960 [kernel:f8a01eb17e20] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 5161845080 [kernel:f9805917a158] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 5258514896 [kernel:f8a001b3b1d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 5799964000 [kernel:f8a01f767d60] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 5881786832 [kernel:f8a01f1601d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 6197270888 [kernel:f8801a9c1968] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 6350540128 [kernel:f8a022444d60] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 6356414928 [kernel:f880137cc1d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 6517550432 [kernel:f8a01f4b6d60] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 6542855408 [kernel:f8a02e933cf0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 6754533720 [kernel:f980647a7158] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 6924487016 [kernel:f8a018420968] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7018662704 [kernel:f8801361db30] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7037142816 [kernel:f88018c32720] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7465709912 [kernel:f88007966158] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7467875312 [kernel:f88007513bf0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7469826392 [kernel:f88006f6b158] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7476650448 [kernel:f880156391d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7517348304 [kernel:f7ffefe1a1d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7517924704 [kernel:f7ffefea6d60] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 7775407456 [kernel:f880026c7d60] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. 8967958992 [kernel:f880109c61d0] Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, Ltd. ALL RIGHTS RESERVED. Greg On Fri, May 15, 2015 at 12:43 PM, Andrew Case &lt;atcuno(a)gmail.com&gt; wrote: > Can you do: > > addrspace().base > > in volshell? > > if base is FileAddressSpace then its a raw file. If its > Elf/crash/hibernation/etc. then its not. > > I am pretty sure pmem would default to ELF or similar. Not many tools do > raw files anymore because of how big 64 bit ones can get with gaps in > the physical address space. > > Thanks, > Andrew (@attrc) > > On 05/15/2015 11:23 AM, Gregory Pendergast wrote: > > So, I thought it was a raw image. Now, not so sure. It was created using > > the winpmem_1.6.2 defaults, with the simple command line: > > winpmem_1.6.2 <output_filename>. The image is from a 64-bit system, so > > it would have defaulted (as I understand it) to using PTE Remapping. > > > > Here's the output of addrspace(): > >>>>addrspace() > > <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object > > > > Thanks, > > Greg > > > > On Fri, May 15, 2015 at 11:57 AM, Michael Ligh &lt;michael.ligh(a)mnin.org > > <mailto:michael.ligh@mnin.org>> wrote: > > > > Hmm, that does not appear to sync up as expected. What format is your > > memory dump? Strings requires a "raw" memory dump. You can check by > > typing addrspace().base in volshell and if its a raw memory dump > > you'll see FileAddressSpace. If you don't have a raw memory image, use > > the imagecopy plugin to create a raw memory dump from whatever format > > you have and then translate the strings again. > > > > MHL > > > > On 5/15/15 11:48 AM, Gregory Pendergast wrote: > >> Thanks gentlemen. No worries there. I didn't take it badly. Sorry > >> for the oversight. > > > >> Correcting the command gives me output, but leaves me with a new > >> question. The string of interest seems nowhere to be found (maybe > >> it's unicode? I'm not sure how to tell...): > > > >>>>> db(0xf9805ba44800) > >> 0xf9805ba44800 00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00 > >> ............(... 0xf9805ba44810 28 00 00 00 18 00 00 00 00 00 00 > >> 00 00 00 02 00 (............... 0xf9805ba44820 00 00 00 00 00 00 > >> 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830 06 > >> 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e............. > >> 0xf9805ba44840 00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00 > >> ................ 0xf9805ba44850 01 00 00 00 40 00 00 00 00 00 00 > >> 00 00 00 00 00 ....@........... 0xf9805ba44860 07 00 07 00 28 00 > >> 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870 38 > >> 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8............... > > > >>>>> db(0xf9805ba44800,length=0xFF) > >> 0xf9805ba44800 00 00 00 00 00 00 00 00 1b 00 01 00 28 00 00 00 > >> ............(... 0xf9805ba44810 28 00 00 00 18 00 00 00 00 00 00 > >> 00 00 00 02 00 (............... 0xf9805ba44820 00 00 00 00 00 00 > >> 00 00 48 a4 83 08 a0 f8 ff ff ........H....... 0xf9805ba44830 06 > >> 09 65 f1 02 00 00 00 00 00 00 00 00 00 00 00 ..e............. > >> 0xf9805ba44840 00 00 00 00 00 00 00 00 a8 00 00 00 00 00 00 00 > >> ................ 0xf9805ba44850 01 00 00 00 40 00 00 00 00 00 00 > >> 00 00 00 00 00 ....@........... 0xf9805ba44860 07 00 07 00 28 00 > >> 40 00 68 00 40 00 18 00 01 00 ....(.@.h.@..... 0xf9805ba44870 38 > >> 00 20 00 04 00 02 00 0b 9e 00 00 00 00 00 00 8............... > >> 0xf9805ba44880 50 14 9e 00 00 00 00 00 03 ee e4 ad 6d 83 d0 01 > >> P...........m... 0xf9805ba44890 03 ee e4 ad 6d 83 d0 01 18 24 3a > >> 05 d4 82 d0 01 ....m....$:..... 0xf9805ba448a0 26 20 00 00 00 00 > >> 00 00 00 00 00 00 00 00 00 00 &............... 0xf9805ba448b0 00 > >> 00 00 00 90 05 00 00 00 00 00 00 00 00 00 00 ................ > >> 0xf9805ba448c0 a0 3f 54 90 00 00 00 00 f2 c6 e4 ad 6d 83 d0 01 > >> .?T.........m... 0xf9805ba448d0 f2 c6 e4 ad 6d 83 d0 01 18 24 3a > >> 05 d4 82 d0 01 ....m....$:..... Here's the string I expect to see > >> based on the strings output: 4397692928 [kernel:f9805ba44800] > >> Copyright (c) 1992-2004 by P.J. Plauger, licensed by Dinkumware, > >> Ltd. ALL RIGHTS RESERVED. > > > >> Thanks again for the help. Greg > > > >> On Fri, May 15, 2015 at 11:30 AM, Michael Ligh > >> &lt;michael.ligh(a)mnin.org <mailto:michael.ligh@mnin.org> > > <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>> wrote: > > > >> Hey Greg....Andrew just (to my surprise) asked me why I was being > >> "rough" on you, so I apologize if that's how it came across...the > >> goal was just to point out the issue as fast as possible. > > > >> MHL > > > >> On 5/15/15 11:15 AM, Michael Ligh wrote: > >>> My command: > > > >>> db(0xf9805ba44800) > > > >>> Your command: > > > >>> db(f9805ba44800) > > > >>> The missing 0x in front makes Python think f9805ba44800 is a > >>> variable name rather than a number. > > > >>> On 5/15/15 11:05 AM, Gregory Pendergast wrote: > >>>> Thanks Michael. I did try that, and received an error. That's > >>>> why I thought I must be doing/forgetting something stupid. Now > >>>> that I'm back at my analysis machine, here's the output: > > > >>>>>>> db(f9805ba44800) > >>>> Traceback (most recent call last): File "<console>", line 1, > >>>> in <module> NameError: name 'f9805ba44800' is not defined > >>>>>>> addrspace() > >>>> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object > >>>> at 0xbef520c> > >>>>> >>>> Note that I'm using Volatilty through the VM provided for the > >>>> most recent class in Reston, in case the version is in > >>>> question. The profile for this sample is WIn7SP1x64. > > > >>>> Thanks, Greg > > > > > > > >>>> On Fri, May 15, 2015 at 10:49 AM, Michael Ligh > >>>> &lt;michael.ligh(a)mnin.org <mailto:michael.ligh@mnin.org> > > <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>> > >> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org> > > <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>> >> wrote: > > > >>>> You would just type db(0xf9805ba44800) in volshell (or > >>>> whatever other address you want to see). > > > >>>> https://github.com/volatilityfoundation/volatility/wiki/Command%20Re > > f > > > >> > e > > > >> >> re > > > > > >>> nce#volshell > >>>> <https://github.com/volatilityfoundation/volatility/wiki/Command%20R > > e > > > >> > f > > > >> >> erence#volshell> > > > >>>> I would also search an electronic copy of the AMF book for > >>>> "volshell" - there are lots of examples. > > > > > >>>> On 5/14/15 10:52 PM, Gregory Pendergast wrote: > >>>>> Thanks Michael. Regarding the latter part of inspecting the > >>>>> data around the strings, that's where I really need the help. > >>>>> I know I can accomplish that with volshell, but I'm not > >>>>> proficient enough yet to know how to get at it. > > > >>>>> If you could provide the necessary commands to get at the > >>>>> data around this hit [kernel:f9805ba44800] as an example, > >>>>> that would be most helpful. > > > >>>>> I'm sure I was doing something n00bishly wrong, but I could > >>>>> never get to the point of displaying the data around that > >>>>> location. I'd be more specific about my attempts, but I'm > >>>>> not in front of my analysis machine right now and don't > >>>>> recall exactly what I tried. > > > >>>>> thanks, greg > > > >>>>>> On May 14, 2015, at 9:39 PM, Michael Ligh > >>>>>> &lt;michael.ligh(a)mnin.org <mailto:michael.ligh@mnin.org> > > <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>> > >>>> <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org> > > <mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>> >>>>>> wrote: > >>>> >>>>> I wouldn't think the module at 0x48706657040b0003 requires > >>>>> investigation. Not only bc its not in the 0xfffff8 range, > >>>>> but you might notice legitimate modules are typically loaded > >>>>> at page aligned base addresses (not XXX0003). Your result > >>>>> looks like a false positive and given the way modscan works > >>>>> (pool scanning) its probably a partially overwritten > >>>>> structure in free/deallocated memory. We *could* put a sanity > >>>>> check in the code to suppress entries that aren't loaded at > >>>>> page aligned addresses, but there are a few exceptions where > >>>>> you'll have modules loaded from non-page aligned addresses. > >>>>> For example, we just looked at a rootkit today in class that > >>>>> is loaded at 0x81b91b80 (on a 32-bit system). Jared's advice > >>>>> is also good - if you ever suspect something like this again, > >>>>> you can use volshell to display the data at the alleged base > >>>>> address and see what's there. If its not an MZ signature, > >>>>> then its probably not a currently loaded module (but keep in > >>>>> mind you can overwrite the MZ with 00 or anything else as a > >>>>> trick...but in that case you'll see real executable code not > >>>>> too far away). > > > >>>>> I would suggest trying to figure out what downloaded the EXE > >>>>> in the first place, so that you can determine what it does > >>>>> after the download finishes (drop to disk and run, drop to > >>>>> disk and run then delete, load directly into memory without > >>>>> touching disk, etc). I would also inspect the data around the > >>>>> strings you found in kernel and free memory - is it verbatim > >>>>> with what you see in the pcap (i.e. just a copy of the > >>>>> packet) or has it been altered (i.e. unpacked, executed, > >>>>> expanded). > > > >>>>>>>> On 5/14/15 4:31 PM, Gregory Pendergast wrote: Just as > >>>>>>>> a follow up to my last reply, the shimcache plugin > >>>>>>>> reported that there was no shimcache data, and the > >>>>>>>> timeliner plugin didn't reveal anything apparently > >>>>>>>> interesting except IE history related to the download. > >>>>>> >>>>>>>> Thanks, Greg > >>>>>> >>>>>> >>>>>>>> On May 14, 2015, at 12:35 PM, Jared Greenhill > >>>>>>>> &lt;jared703(a)gmail.com <mailto:jared703@gmail.com> > > <mailto:jared703@gmail.com <mailto:jared703@gmail.com>> > >> <mailto:jared703@gmail.com <mailto:jared703@gmail.com> > > <mailto:jared703@gmail.com <mailto:jared703@gmail.com> >>>> <mailto:jared703@gmail.com <mailto:jared703@gmail.com> > > <mailto:jared703@gmail.com <mailto:jared703@gmail.com>> > >> <mailto:jared703@gmail.com <mailto:jared703@gmail.com> > > <mailto:jared703@gmail.com <mailto:jared703@gmail.com>>>>> wrote: > >>>>>> >>>>>>>>> Hey Greg, > >>>>>>> >>>>>>>>> A couple thoughts/ideas: > >>>>>>> >>>>>>>>> What was the initial reason for investigation- the > >>>>>>>>> suspect EXE? Do you have a timeframe of the suspect > >>>>>>>>> activity? > >>>>>>> >>>>>>>>> What was the context around the suspect EXE > >>>>>>>>> download, just the PCAP or? If so, did the memory > >>>>>>>>> capture occur when there was still an active > >>>>>>>>> connection? Sometimes this can be a dealbreaker when > >>>>>>>>> the connection isn't there. > >>>>>>> >>>>>>>>> Does moddump work on the module with that base > >>>>>>>>> address? If so, what type of strings are you seeing? > >>>>>>> >>>>>>>>> As far as execution goes, does the shimcache plugin > >>>>>>>>> provide any results around the time of interest? > >>>>>>>>> Assuming you have a time of interest, you could also > >>>>>>>>> try the timeliner plugin to pull in other temporal > >>>>>>>>> artifacts to hone in around that suspect time. > >>>>>>> >>>>>>>>> hope this helps, Jared - @jared703 > >>>>>>> >>>>>>> >>>>>>>>> On Tue, May 12, 2015 at 3:36 PM, Gregory Pendergast > >>>>>>>>> &lt;greg.pendergast(a)gmail.com <mailto:greg.pendergast@gmail.com> > >>>>>>>>> <mailto:greg.pendergast@gmail.com > > <mailto:greg.pendergast@gmail.com>> > >>>>>>>>> <mailto:greg.pendergast@gmail.com > > <mailto:greg.pendergast@gmail.com> > >> <mailto:greg.pendergast@gmail.com <mailto:greg.pendergast@gmail.com> >>>>>>>>> <mailto:greg.pendergast@gmail.com > > <mailto:greg.pendergast@gmail.com> > >> <mailto:greg.pendergast@gmail.com <mailto:greg.pendergast@gmail.com>> > >>>> <mailto:greg.pendergast@gmail.com <mailto:greg.pendergast@gmail.com> > >> <mailto:greg.pendergast@gmail.com > > <mailto:greg.pendergast@gmail.com>>>>> wrote: > >>>>>>> >>>>>>>>> Greeting, > >>>>>>> >>>>>>>>> I'm examining a memory sample (captured locally with > >>>>>>>>> winpmem_1.6.2) <yeah...i know...> > >>>>>>> >>>>>>>>> Modscan shows one apparently strange module that has > >>>>>>>>> no name and no file listed. The base address space > >>>>>>>>> also seems way out of whack for the rest of the > >>>>>>>>> sample. > >>>>>>> >>>>>>>>> So all i have are offset, base, and size: > >>>>>>>>> 0x000000023a80b540 0x48706657040b0003 0xf3a54f0 > >>>>>>> >>>>>>>>> In particular, that base address seems way out of > >>>>>>>>> range compared to everything else in 0xfffff8.... > >>>>>>>>> space > >>>>>>> >>>>>>>>> How can I tell if this is an error of some kind in > >>>>>>>>> the captured sample versus a legitimate anomaly that > >>>>>>>>> bears investigation? > >>>>>>> >>>>>>> >>>>>>>>> Lastly, and pardon me if this is a n00b question, > >>>>>>>>> but how can I determine why specific strings appear > >>>>>>>>> in kernel memory (based on strings plugin output)? > >>>>>>>>> For context, I have a suspicious executable download, > >>>>>>>>> but there appears to be no evidence of the file in > >>>>>>>>> $MFT (I don't have access to UsnJrnl) and I'm trying > >>>>>>>>> to find out what happened to it and whether it ran. > >>>>>>>>> Strings from the executable (ontained from pcap) do > >>>>>>>>> appear in Free Memory and Kernel memory, but I'm not > >>>>>>>>> clear whether that's a symptom of the download or a > >>>>>>>>> sign of execution. > >>>>>>> >>>>>>>>> Thanks, greg >