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

Gregory Pendergast greg.pendergast at gmail.com
Sat May 30 09:17:34 CDT 2015


Thanks for getting back to me Michael. I'll ask my management about
sharing the sample next week and get back to you off list. I believe
we had another sample recently that was showin the same issue. Another
analyst was examining that one, so I'll  check on that one first.

G

> On May 29, 2015, at 10:00 PM, Michael Ligh <michael.ligh at mnin.org> wrote:
>
> -----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