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
==============================
Hello
I've been testing volatility and looking through the results. In
particular, within the Handles extraction, I found the following line...
0xfffffa8009648800 3544 0x1a78 0x120089 File
\Device\TrueCryptVolumeK\Test.txt
This is a file that I had stored in a hidden volume. I attempted to
re-create this type of entry with 3 further memory dumps with no such
success (No files within TrueCrypt volume). Can anyone advise why this
filename "Test.txt" was found? I see that a lot of files can be found in
the Handles extraction, but haven't been able to find any documentation on
how files are included in this section.
I ran the following command on an 8GB Memory dump which was captured via
FTK Imager...
vol.exe -f memdump.mem --profile=Win7SP1x64 --output=text
--output-file=handles-files.txt handles -t File
This result was a total surprise to find. In further testing, I attempted
to do the following within the hidden volume...
- Create new files
- Copy files into the volume
- Leave files open while closing the volume within TrueCrypt
Thanks,
R
