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 <mailto:atcuno@gmail.com>> 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: using system, so &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>>>> 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>> <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>> <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>> <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> <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 _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF0EAREKAAYFAlVpGZ0ACgkQXnt9v1O0LIuMhgD2LICs3DwjqYaU5j+RD+l69+cL fZWHLRVe+HedTVjtvAD/fwKk2D3qAtlXzliEXw0rLIP4IcBE3Mp77g57gYSFc6c= =Zbsg -----END PGP SIGNATURE-----