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

Michael Ligh michael.ligh at mnin.org
Fri May 29 20:59:57 CDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Greg,

Sorry for the delay getting back to you. This output continues to
confuse me. Is there any chance you can share the memory sample so I
can dig a bit deeper?

NDA's are not a problem. Feel free to reply off-list.

Cheers,
MHL

On 5/15/15 1:03 PM, Gregory Pendergast wrote:
> Thanks Andrew. That confirms it's a raw file.
> 
>>>> addrspace().base
> <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:
> 
>>>> db(0xf8a0051f40ae)
> 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
> <atcuno at gmail.com <mailto:atcuno at 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:
>> 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
> <michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
>> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at 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 .... at ...........
>>> 0xf9805ba44860  07 00 07 00 28 00 40 00 68 00 40 00 18 00 01 00
>>> ....(. at .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 .... at ...........
>>> 0xf9805ba44860  07 00 07 00 28 00 40 00 68 00 40 00 18 00 01 00
>>> ....(. at .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 
>>> <michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>>
>> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at 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 
>>>>> <michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>>
>> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>>>
>>> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>>
>> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at 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 
>>>>>>> <michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>>
>> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>>>
>>>>> <mailto:michael.ligh at mnin.org
>>>>> <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>>
>> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
> <mailto:michael.ligh at mnin.org <mailto:michael.ligh at 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 
>>>>>>>>> <jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>>
>> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>>>
>>> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>>
>> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>>>>
>>>>> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>>
>> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>>>
>>> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>>
>> <mailto:jared703 at gmail.com <mailto:jared703 at gmail.com>
> <mailto:jared703 at gmail.com <mailto:jared703 at 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 <greg.pendergast at gmail.com
> <mailto:greg.pendergast at gmail.com>
> <mailto:greg.pendergast at gmail.com 
> <mailto:greg.pendergast at gmail.com>>
>>>>>>>>>> <mailto:greg.pendergast at gmail.com
> <mailto:greg.pendergast at gmail.com>
>> <mailto:greg.pendergast at gmail.com
>> <mailto:greg.pendergast at gmail.com>>>
>>>>>>>>>> <mailto:greg.pendergast at gmail.com
> <mailto:greg.pendergast at gmail.com>
>> <mailto:greg.pendergast at gmail.com
>> <mailto:greg.pendergast at gmail.com>>
>>> <mailto:greg.pendergast at gmail.com
> <mailto:greg.pendergast at gmail.com>
> <mailto:greg.pendergast at gmail.com 
> <mailto:greg.pendergast at gmail.com>>>>
>>>>>>>>>> <mailto:greg.pendergast at gmail.com
> <mailto:greg.pendergast at gmail.com>
>> <mailto:greg.pendergast at gmail.com
>> <mailto:greg.pendergast at gmail.com>>
>>> <mailto:greg.pendergast at gmail.com
> <mailto:greg.pendergast at gmail.com>
> <mailto:greg.pendergast at gmail.com 
> <mailto:greg.pendergast at gmail.com>>>
>>>>> <mailto:greg.pendergast at gmail.com
> <mailto:greg.pendergast at gmail.com>
> <mailto:greg.pendergast at gmail.com 
> <mailto:greg.pendergast at gmail.com>>
>>> <mailto:greg.pendergast at gmail.com
>>> <mailto:greg.pendergast at gmail.com>
>> <mailto:greg.pendergast at gmail.com
> <mailto:greg.pendergast at 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 at 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-----


More information about the Vol-users mailing list