We are very happy to announce that you can now see the table of contents
and search through the Art of Memory Forensics on Amazon!
http://amzn.to/1o3ACn7
This book, written by the core Volatility developers, is over 900 pages
of memory forensics and malware analysis across Windows, Mac, and Linux.
It will be officially released at Blackhat and around this time it will
also be available through Amazon and other retailers. It will be
available in both hard copy and digital formats.
If you have any questions about the book please let us know, and we will
have more information about the release at Blackhat as it gets closer.
--
Thanks,
Andrew (@attrc)
We wanted to give everyone a quick update on some recent events in the
Volatility community.
First, the submissions for the Open Source Digital Forensics Conference
are available for voting. This conference's talk selection works by
posting each CFP submission in anonymized form and choosing talks based
on voting feedback from the community.
All of the talks can be found here:
http://www.basistech.com/osdfcon/osdfcon-vote-for-presentations
The submission from the Volatility Team is 'Next Generation Memory
Forensics'. If it sounds interesting to you then please give it a +1!
Second, our submission to Blackhat Arsenal was accepted!
https://www.blackhat.com/us-14/arsenal.html#Ligh
At this event we will be releasing the highly anticipated Volatility 2.4
that includes support for Windows 8, 8.1, 2012, 2012 R2 as well as new
plugins for Truecrypt, Linux, and Mac.
As Blackhat gets closer we will have more information on other events
there including a book signing and release party.
Finally, we now have a LinkedIn group for the Volatility and memory
forensics community:
https://www.linkedin.com/groups?mostRecent=&gid=8128809
This group is meant to allow analysts and researchers to ask questions,
learn from each other, and network. The group is open to all but marked
private to (hopefully) avoid spam.
--
Thanks,
Andrew (@attrc)
Hello all,
I'm analyzing a malware sample that is doing process hollowing. While
doing dynamic analysis, with Process Explorer open, I can see the
legitimate EXE (that appears to get hollowed) get started by the
malware, and is then orphaned as the malware terminates itself. A few
seconds later I see network communication starting.
The malfind plugin identifies the process as malware but when I try to
dump process from memory, the strings on the dumped process look the
same as the strings of the legitimate file in the System32 folder.
Using the yarascan plugin (following the example on the wiki) I'm able
to locate some strings (domain name, IP address, file requested by
GET) that are associated with the PID of the suspected hollowed
process.
Oh, and the malware is packed so I assume the unpacked code is being
placed into the address space of the legitimate file in memory.
The capture is a .vmem from a VM snapshot.
Any thoughts on how I can locate the unpacked code in memory?
Shouldn't dumping the PID with procexedump contain the unpacked code?
I've dumped the process by PID and physical offset (from psscan).
Thanks,
Carlos
Hi all,
Android Memory acquisition will be part of a paper I have to write. So
far I have no problem to follow the description for an AVD on
https://code.google.com/p/volatility/wiki/AndroidMemoryForensic
Please excuse this noob question (and my bad English) but I'm going
crazy figuring this out:
Can LiME be used in real life Android forensics that is Android memory
is acquired without having to reboot the Android device beforehand?
Let's say:
I get an running Android mobile phone and for some lucky reason it is
both rooted and the user interface unlocked. (Are there any statistics
available how often this is the case?) My task is to acquire its RAM.
As far as I understood in order to use Lime for RAM acquisition I have to
a) get the Android kernel's source code from the manufacturer,
b) cross compile a new kernel with some settings for later being able to
insmod the LiME kernel module,
c) flash the compiled kernel onto the phone and
d) reboot the phone to get the new kernel running, which
e) destroys all the RAM I wanted to acquire, before I can
f) insmod LiME.
Please be patient and give me a hint where I'm going wrong?!
All papers I found so far used prepared phones.
Thanks a lot and have a nice weekend,
Philipp
There are many new developments in the world of Volatility that we are
now happy to announce.
- The 2014 Volatility Plugin Contest has started
- We will be hosting a public training in Austin in December
- We have partnered with GMG Systems to provide our students access to
what we consider to be the most accurate and reliable memory acquisition
tool available
- The Volatility Foundation website is now live
For complete information on these and more, please see the following
blog post:
http://volatility-labs.blogspot.com/2014/05/volatility-update-all-things.ht…
--
Thanks,
Andrew (@attrc)
Dear sir,
Currently we doing investigate an security breach, our server is CentOS 5.8. After dump memory raw, we can not processing with Volatility. We have read the topic :
http://lists.volatilityfoundation.org/pipermail/vol-users/2013-February/000…
After edit to that DTB we found it work on LIME profile but doesn't work on Raw memory dump. Can we have some instruction how to convert Raw memory to LIME? Or how to debug to find correct DTB in raw memory only?
Btw, we trying to brute force like your advise but it very long since the range is from -0x200000 -> 0x200000.
Regards,
I'm looking for a patch-set that gets OSX 9.2 dumps from OSXPmem at
least marginally working. I know it's supposed to be in the upcoming
vol-2.4 release, but I'ld really like to see the progress/use
volatility instead of having to beat volafox in to shape to get 9.2
dumps to work.
Hi all,
I'm trying to understand what I've misunderstood.
Consider this entry from a run of vadinfo:
VAD node @ 0x84f1f3b0 Start 0x7ffde000 End 0x7ffdefff Tag Vadl
Flags: CommitCharge: 1, MemCommit: 1, NoChange: 1, PrivateMemory: 1, Protection: 4
Protection: PAGE_READWRITE
Vad Type: VadNone
First prototype PTE: 94181720 Last contiguous PTE: 94181728
This node represents a range which is private (PrivateMemory: 1).
If it's private, i.e. not shareable, why are there Prototype PTEs?
I though prototype PTEs were only used when a range was shareable?
I have a few Vadl nodes like this. The VadS nodes in the output with 'PrivateMemory: 1' don't show any prototype PTEs.
Any pointers greatly appreciated.
Hello all,
Just wanted to let people know I have released a USN Journal record parser plugin for volatility.
https://github.com/tomspencer/volatility/tree/master/usnparser
For anyone who wants a refresher on the USN journal and its forensic significance, I recommend these <http://journeyintoir.blogspot.com/2013/01/re-introducing-usnjrnl.html> sites <http://securitybraindump.blogspot.com/2011/07/dear-diary-today-i-was-infect…> . The USN journal has been very useful to us in a variety of circumstances, so I highly recommend including it in your work/timelining flow if you dont already. Ive even seen situations where journal records from external NTFS volumes persist in memory even after the device is removed, but those results have been inconsistent.
This plugin should work on any version of Windows that does USN journaling (Vista/2008 and up, XP SP3 if you specifically turn it on), and it should play well with Unicode file names including calling out special Unicode characters like directional changes.
For an example of calling out direction changes:
2014-04-16 20:51:23.116,0x257L,0x3L,0x14de3L,0x3L,0x4806360L,"utf-canary.<RLO>txt.scr",RENAME_NEW_NAME & CLOSE,ARCHIVE
The <RLO> indicates a Unicode Right-To-Left Override character. This means that although the actual filename extension was txt.scr, a screen saver filetype which is expected to be an executable, it would have appeared to the user as utf-canary.rcs.txt which most users would expect to be a text file they could safely click.
This is my first volatility plugin so Id love any feedback/suggestions/questions. Based on some feedback from MHL I'll be doing some testing to see if I should turn on timestamp validation by default, but I'm open to other changes/additions people would like to see.
Basic notes on the plugin are below. Enjoy!
Thanks,
Tom
A note on USN record versions. The literature I can find seems to suggest that starting with Windows NT 6.2 families (8/2012) the OS should be using version 3 records, and this plugin does support these records. That said, testing has shown that at least in memory, these OSs still seem to use v2 records. As such, unless otherwise specified with the -R3 flag, this plugin will always assume v2 records.
In my testing there has been a significant number of duplicates in memory, so piping to sort u can be effective.
Invocation example:
CSV output
$ vol.py --profile Win7SP1x64 -f Windows7SP1x64.vmem usnparser --output=csv
Volatility Foundation Volatility Framework 2.3.1
timestamp,MFTEntry,MFTEntryUSN,Parent,ParentUSN,usn#,"Filename",Reason,Attributes
2014-01-26 09:01:19.079,0x5056L,0x1L,0x7beL,0x1L,0x10f35c0L,"ngen_service.log",EXTEND & CLOSE,ARCHIVE
2014-01-26 09:01:19.079,0x7d8L,0x86L,0x7beL,0x1L,0x10f3620L,"ngen_service.lock",CREATE & DELETE & CLOSE,ARCHIVE
2014-01-26 09:01:19.142,0x7d8L,0x89L,0x28eL,0x1L,0x10f39d8L,"GACLock.dat",CREATE,ARCHIVE & TEMPORARY
2014-01-26 09:01:19.142,0x7d8L,0x89L,0x28eL,0x1L,0x10f3a30L,"GACLock.dat",CREATE & DELETE & CLOSE,ARCHIVE & TEMPORARY
....
BODY output, suitable for using with mactime
$ vol.py --profile Win7SP1x64 -f Windows7SP1x64.vmem usnparser --output=body | head
Volatility Foundation Volatility Framework 2.3.1
0|[USN JOURNAL] ngen_service.log EXTEND & CLOSE/USN: 17774016/PARENT MFT: 1982|20566|---a-----------|0|0|0|1390726879|1390726879|1390726879|1390726879
0|[USN JOURNAL] ngen_service.lock CREATE & DELETE & CLOSE/USN: 17774112/PARENT MFT: 1982|2008|---a-----------|0|0|0|1390726879|1390726879|1390726879|1390726879
0|[USN JOURNAL] GACLock.dat CREATE/USN: 17775064/PARENT MFT: 654|2008|---a--t--------|0|0|0|1390726879|1390726879|1390726879|1390726879
0|[USN JOURNAL] GACLock.dat CREATE & DELETE & CLOSE/USN: 17775152/PARENT MFT: 654|2008|---a--t--------|0|0|0|1390726879|1390726879|1390726879|1390726879
The current version's help output (flags specific to usnparser start at "-T, --timestamp"):
$ vol.py usnparser -h
Volatility Foundation Volatility Framework 2.3.1
Usage: Volatility - A memory forensics analysis platform.
Options:
-h, --help list all available options and their default values.
Default values may be set in the configuration file
(/etc/volatilityrc)
--conf-file=/home/vol/.volatilityrc
User based configuration file
-d, --debug Debug volatility
--plugins=PLUGINS Additional plugin directories to use (colon separated)
--info Print information about all registered objects
--cache-directory=/home/vol/.cache/volatility
Directory where cache files are stored
--cache Use caching
--tz=TZ Sets the timezone for displaying timestamps
-f FILENAME, --filename=FILENAME
Filename to use when opening an image
--profile=WinXPSP2x86
Name of the profile to load
-l LOCATION, --location=LOCATION
A URN location from which to load an address space
-w, --write Enable write support
--dtb=DTB DTB Address
--output=text Output in this format (format support is module
specific)
--output-file=OUTPUT_FILE
write output in this file
-v, --verbose Verbose information
--shift=SHIFT Mac KASLR shift address
-g KDBG, --kdbg=KDBG Specify a specific KDBG virtual address
-k KPCR, --kpcr=KPCR Specify a specific KPCR address
-T, --timestamp Print timestamps instead of human-readable dates
-E, --unixtime Use Unix Epoch 32-bit timestamps instead of native
Windows 64-bit timestamps (loses subsecond accuracy).
DOES NOT imply -T above.
-C, --checktime Don't show entries with timestamps outside of unix
epoch range to reduce corrupt entries
-S, --strict Enable stricter checks on record integrity to further
reduce corrupt entries
-O, --offset Show the physical offset for each record
-R RECORDTYPE, --recordtype=RECORDTYPE
Force version of USN record (2 or 3) to search for. In
testing so far all OS's seem to use version 2 records
in memory (even 8.1/2012r2 which purport to use R3).
As such, default is R2.
-U, --unicode Show unicode (utf-8) filenames. Be aware that due to
corrupted records there will likely be strange
characters in some places. Using -C and -S can help
cut this down.
---------------------------------
Module USNParser
---------------------------------
Scans for and parses USN journal records
Hi,
According to Volatility issue #383 'tmpfs' extraction doesn't work because Volatility doesn't support NUMA systems.
Question 1 - Is it on the roadmap for future versions?
I deal primarily with Multi-CPU cloud systems so this is definitely a desired feature.
Question 2- Is it reasonably feasible to manually extract tmpfs from a system RAM dump?
Following the 'linux_tmpfs' module through the debugger showed that it was able to locate the /dev/shm tmpfs file system (replicating 2 levels in my output directory), it just croaked when it came time to retrieve the actual file data.
I figure that if I can manually determine whatever offset it needs then I can set the proper variable in a debug session.
Any thoughts?
Thanks,
Geoff
==============================
Geoff Torres HP Global Cyber Security
8000 Foothills Blvd.
Roseville, CA. 95747
916-785-3323
==============================
