10:17 a.m.
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(a)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.
<mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>
https://github.com/volatilityfoundation/volatility/wiki/Command%20Re
f
<mailto:jared703@gmail.com <mailto:jared703@gmail.com>>
<mailto:greg.pendergast@gmail.com>>>>>> wrote:
-----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----- >> 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(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:
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():
<michael.ligh(a)mnin.org
<mailto:michael.ligh@mnin.org>
>> addrspace()
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object
Thanks, Greg
On Fri, May 15, 2015 at 11:57 AM, Michael Ligh <mailto:michael.ligh@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
<mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>
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
> <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
>>> <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>>
<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).
e
<https://github.com/volatilityfoundation/volatility/wiki/Command%20R
e
re
>> nce#volshell
f
<mailto:michael.ligh@mnin.org <mailto:michael.ligh@mnin.org>>
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(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>>
<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
>>>>>>> <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>>
<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 <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
<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
>>>>>>>>
>>>>>>>> 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