Has anyone encountered DEST records in index.dat files? I looked at the
source code and docs of open source tools that parse index.dat/MSHIST
files and I don't see any reference to DEST records...
I ask as I was digging around a memory sample that I generated to look
at IE records, and saw this:
0x04517313 a7 c2 cf 11 bf f4 44 45 53 54 00 00 16 00 08 00
......DEST......
0x04517323 66 63 03 00 00 00 da 00 68 63 28 00 01 00 82 00
fc......hc(.....
0x04517333 00 00 c2 c5 41 6e 03 c7 d1 01 c2 cd 17 57 2d c7
....An.......W-.
0x04517343 d1 01 01 00 00 00 00 00 00 00 00 00 00 00 3a 00
..............:.
0x04517353 32 00 30 00 31 00 36 00 30 00 36 00 31 00 35 00
2.0.1.6.0.6.1.5.
0x04517363 32 00 30 00 31 00 36 00 30 00 36 00 31 00 36 00
2.0.1.6.0.6.1.6.
0x04517373 3a 00 20 00 56 00 61 00 41 00 41 00 41 00 40 00
:...S.a.l.t.r.@.
0x04517383 68 00 74 00 74 00 70 00 3a 00 2f 00 2f 00 77 00
h.t.t.p.:././.w.
0x04517393 77 00 77 00 2e 00 6e 00 62 00 63 00 2e 00 63 00
w.w...n.b.c...c.
0x045173a3 6f 00 6d 00 2f 00 00 00 4e 00 42 00 43 00 20 00
o.m./...N.B.C...
0x045173b3 54 00 56 00 20 00 4e 00 65 00 74 00 77 00 6f 00
T.V...N.e.t.w.o.
0x045173c3 72 00 6b 00 20 00 2d 00 20 00 53 00 68 00 6f 00
r.k...-...S.h.o.
0x045173d3 77 00 73 00 2c 00 20 00 45 00 70 00 69 00 73 00
w.s.,...E.p.i.s.
0x045173e3 6f 00 64 00 65 00 73 00 2c 00 20 00 53 00 63 00
o.d.e.s.,...S.c.
0x045173f3 68 00 65 00 64 00 75 00 6c 00 65 00 00 00 00 00
h.e.d.u.l.e.....
The strings are in unicode, but you can see the DEST marker followed by
binary timestamps, followed by the traditional hist format of
DATEDATE:machine@URL ....
If DEST records don't appear on disk, then maybe they are a memory-only
data structure? I would like to convert carving for these into a
Volatility plugin, but I want to make sure I understand any prior work
on them first.
--
Thanks,
Andrew (@attrc)
I'm analyzing a Vista SP2 system that was compromised via a Remote Desktop
login (somehow the culprit had access to correct login credentials).
Security.evtx only contains information about this single illegal login
(and there is no indications that the eventlog was cleared)
The strange thing is that carving though memory for network packets (using
CapLoader) I find packets showing RDP traffic to additional IPs, not only
the one found in Security.evtx
Any help in trying to put some contex around these additional IPs found in
memory, using volatility, or traditional disk forensics is highly
appreciated!
(The machine had only been running for about a week before the intrusion,
so anything found in memory should in theory be backed up by information in
eventlog)
Jarle Thorsen
All,
I have a hibernation file from a Windows 7 machine that when I run hibinfo against it, I get the output below. Has anyone seen this before? I'm using the latest version of volatility from github, as of today. The command I used was vol.py -f hiberfil.sys --profile==Win7SP1x86 hibinfo. Other plugins fail as well. Converting the file to raw format using imagecopy and using other plugins didn't work either.
Thanks for the help!Kevin
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VMWareMetaAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
VMWareAddressSpace: No base Address Space
QemuCoreDumpElf: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace64BitMap: Header signature invalid
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VMWareMetaAddressSpace: VMware metadata file is not available
VirtualBoxCoreDumpElf64: ELF Header signature invalid
VMWareAddressSpace: Invalid VMware signature: 0x0
QemuCoreDumpElf: ELF Header signature invalid
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile Win7SP1x86 selected
IA32PagedMemoryPae: No valid DTB found
IA32PagedMemory: No valid DTB found
OSXPmemELF: ELF Header signature invalid
FileAddressSpace: Must be first Address Space
ArmAddressSpace: No valid DTB found
Hi,
I've recently used linux_netstat with different Linux memory images
and noticed that the destination port for established outgoing connections
is always shown as "0".
The source port for incoming connections is shown correctly.
Any way to fix this and get the correct destination port for outgoing
connections?
Thanks,
Thomas
Hello list,
I’m trying to use Volatility on an OSX memory dump. I was unable to download mac memory reader as the site is offline. I’ve used osxpmem from recall.
The commands I used to perform the dump were:
sudo kextutil MacPmem.kext
sudo ./osxpmem --format elf -o ./ram.dump
I then moved ram.dump into my volatility directory
To check my downloaded profile is included I’ve run the command
./volatility_2.5_mac --plugins=./mac —imageinfo
and then I ran
./volatility_2.5_mac --plugins=./mac --profile=MacElCapitan_10_11_4_15E65x64 -f ../ram.dump mac_pslist
and got
Volatility Foundation Volatility Framework 2.5
Offset Name Pid Uid Gid PGID Bits DTB Start Time
------------------ -------------------- -------- -------- -------- -------- ------------ ------------------ ----------
No suitable address space mapping found
Tried to open image as:
MachOAddressSpace: mac: need base
LimeAddressSpace: lime: need base
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace64BitMap: No base Address Space
VMWareMetaAddressSpace: No base Address Space
WindowsCrashDumpSpace64: No base Address Space
HPAKAddressSpace: No base Address Space
VirtualBoxCoreDumpElf64: No base Address Space
QemuCoreDumpElf: No base Address Space
VMWareAddressSpace: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
IA32PagedMemoryPae: No base Address Space
IA32PagedMemory: No base Address Space
OSXPmemELF: No base Address Space
MachOAddressSpace: MachO Header signature invalid
LimeAddressSpace: Invalid Lime header signature
WindowsHiberFileSpace32: PO_MEMORY_IMAGE is not available in profile
WindowsCrashDumpSpace64BitMap: Header signature invalid
VMWareMetaAddressSpace: VMware metadata file is not available
WindowsCrashDumpSpace64: Header signature invalid
HPAKAddressSpace: Invalid magic found
VirtualBoxCoreDumpElf64: ELF Header signature invalid
QemuCoreDumpElf: ELF Header signature invalid
VMWareAddressSpace: Invalid VMware signature: 0x4034b50
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Failed valid Address Space check
IA32PagedMemoryPae: Failed valid Address Space check
IA32PagedMemory: Failed valid Address Space check
OSXPmemELF: ELF Header signature invalid
FileAddressSpace: Must be first Address Space
ArmAddressSpace: Failed valid Address Space check
Apparently my OSXPmemElf signature is invalid. What can I do to dump memory with a valid signature? Or does my problem lie elsewhere?
Regards,
Rob
Dear list,
Is it possible to extend the built in profiles for the standalone mac version of volatility with extra ones?
I’ve downloaded the linux and mac profiles from github and tried putting them in a subdirectory as with the source code version on Linux i.e. volatility_2.5.mac.standalone/volatility/plugins/overlays/mac
However they don’t show up in the profile list when I run volatility_2.5.mac.standalone —info
Regards,
Rob
Hi,
thanks to your suggestion, I make great progresses but I still not get
the target: localize the master password of an android app.
I run the app and set a password as "mypassword2016". With yarascan I
was able to see that this password is store in memory in unicode (I run
"python vol.py linux_yarascan -W -A -Y "mypassword2016"").
Then, I would like to see if there some "signature" that helps me to
locate the password. So I decide to use volshell and see around the
passwod, but I have no luck (see the attachment, where I showed that
there is before and after of the two occurrences of the password
"mypassword2016").
Of course I've repeated the same workflow for other two passwords, but I
did not get anything that helps me to figure out if there is way to
locate where the password is store.
Do you have any suggestion, please?
Thanks in advance,
Massimo
Hi Laurent,
Not necessarily. You're assuming that everything once in memory stays in
memory...which isn't the case. If you have an IP and you pass it to
ws2_32.connect() and then free or overwrite the memory containing the
IP...the connection stays up and running just fine. It could also be
swapped to the page file.
MHL
On 5/17/16 5:14 AM, Laurent LF wrote:
> Thanks Michael,
>
> What I don't understand is that yarascan on the "IP to integer" value on
> the full mem dump gives a result in the svchost process only and not
> anywhere else. I should have at least two occurences, one in the svchost
> process and one other in the System process, right ?
>
> Thanks,
>
> Laurent
>
>
> On 2016-05-12 23:18, Michael Ligh wrote:
>> I can't speak to whether its "normal" but its not surprising. The System
>> process is the default home for threads that start in kernel mode. Thus
>> any kernel driver using the winsock APIs for networking will make it
>> appear as if the System process is responsible. Now combine that with a
>> DLL that's implementing a particular service (and running inside
>> svchost.exe process) who wants to communicate with its corresponding
>> driver...it could send an IOCTL and say "go connect to this x.x.x.x IP
>> address." In that case you could easily end up with a reference to the
>> IP in svchost.exe.
>>
>> MHL
>>
>> On 5/10/16 2:34 PM, Laurent LF wrote:
>>> Hi,
>>>
>>> I have progressed a bit on this.
>>> I was first limiting my IP addresses searches on the process returned by
>>> "netscan", which was "System" with pid=4. As I was convinced I should
>>> have got some results within "System", I supposed I was wrong with the
>>> syntax or the IP representation and made several other tries (IP as
>>> string, little indian ordering as suggested by Andrew,...), still with
>>> pid=4. I also made a few tries on the whole memory dump but with no
>>> luck. It looks like I was doing something wrong because today I made
>>> some tries again on full memory dump and finally found the IPs (Big
>>> Indian ordering) in ... a "svchost" process.
>>>
>>> I still need to go deeper in the analysis (as far as my little knowledge
>>> will allow me to go :-) ) but is it normal behavior to have netscan
>>> reporting some connections linked with "System" when IP search with
>>> yarascan on given IPs returns only a "svchost" process ?
>>> Also, I was expecting to find references to the IPs in several memory
>>> locations but only one occurence in this case, in the given svchost
>>> process...
>>>
>>> Thanks,
>>> Laurent
>>>
>>>
>>> Le 10/05/2016 17:14, Michael Ligh a écrit :
>>>> Also note yarascan only accesses available pages. The IP could be in a
>>>> page that's swapped to the pagefile or in a page that's been
>>>> freed/deallocated and is no longer referenced from any page
>>>> table(s). In
>>>> the later case, you could find it by extracting strings from the memory
>>>> dump or by scanning with yara signatures across the memory dump file
>>>> (i.e. not caring about virtual address spaces)...however if you find it
>>>> in either of two methods, there's no way to trace the page back to its
>>>> owner.
>>>>
>>>> MHL
>>>>
>>>> On 5/10/16 7:56 AM, Andrew Case wrote:
>>>>> Hey,
>>>>>
>>>>> Did you try the IP hex value in reverse? It is likely that the IP
>>>>> address is stored as little endian in memory.
>>>>>
>>>>> Thanks,
>>>>> Andrew (@attrc)
>>>>>
>>>>> On 05/10/2016 05:15 AM, tech(a)nisteo.fr wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I am starting to play with Volatility (2.5) and I am currently
>>>>>> working
>>>>>> on a Win2008R2 image (memory dump with winpmem). I would like to
>>>>>> understand what is causing some network connections initiated by the
>>>>>> "System" process.
>>>>>> netscan shows those connections and I would like to be able to find
>>>>>> references to the IP addresses in the memory dump. I have tried
>>>>>> "yarascan -Y" plugin with the IP string, with the IP to integer value
>>>>>> (converted to Hex) but no luck finding IPs that , however, I can
>>>>>> see in
>>>>>> the netscan result...
>>>>>> Either I am wrong with the yarascan syntax or there is something I
>>>>>> don't
>>>>>> know regarding how Win2008 stores IP...
>>>>>>
>>>>>> Any hints ?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Laurent
>>>>>> _______________________________________________
>>>>>> Vol-users mailing list
>>>>>> Vol-users(a)volatilityfoundation.org
>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>
>>>>> _______________________________________________
>>>>> Vol-users mailing list
>>>>> Vol-users(a)volatilityfoundation.org
>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>
>>>
>>>
>
>
Hi all,
Wondering if anybody's come across this scenario...
I want to read an address from my_offset:
my_address = obj.Object('address', offset=my_offset, vm=task_vm)
However, for Wow64 the address should only be 4 bytes, but because we're
analysing with a 64-bit profile, 'address' will cause 8 bytes to be parsed
(right?).
Do I need to replace it with something like:
if profile_is_32bit or process_is_wow64:
my_address = obj.Object('unsigned long', offset=my_offset, vm=task_vm)
else:
my_address = obj.Object('unsigned long long', offset=my_offset,
vm=task_vm)
Or do I need to start manually unpacking structs?
Thanks,
Adam
