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 - @jared703On Tue, May 12, 2015 at 3:36 PM, Gregory Pendergast <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