Volatility
Base Command
help flag
The -h flag gives configuration information in Volatility
Used alone it identifies the version, currently loaded plugins, and
common parameters
Use -h with a plugin to get details and plugin-specific usage
System Profile
imageinfo
The imageinfo output tells you the suggested profile that you should pass as the parameter to --profile=PROFILE when using other plugins. Since the profile tells volatility the format and type of memory objects that should be present in the RAM dump, getting the profile correct is an important first step before any further analysis.
kgdbscan
To further narrow down the most likely profile, the above command will use the kernel debugger data block scan plugin to make a profile suggestion based on the KDBG header.
System Process
Analysing System Process
Volatility provides a few commands you can use for extracting information about processes:
pslist finds and walks the doubly linked list of processes and prints a summary of the data. This method typically cannot show you terminated or hidden processes.
pstree takes the output from pslist and formats it in a tree view, so you can easily see parent and child relationships.
psscan scans for _EPROCESS objects instead of relying on the linked list. This plugin can also find terminated and unlinked (hidden) processes.
psxview locates processes using alternate process listings, so you can then crossreference different sources of information and reveal malicious discrepancies.
pslist
Three browsers are running (two instances of IEXPLORE.EXE and one firefox .exe), an e‑mail client (thunderbird.exe), and Adobe Reader (AcroRd32.exe). Thus, this machine is very likely to be a client or workstation, as opposed to a server.
Furthermore, if you suspect a client-side attack vector (such as a drive-by download or phishing exploit), it is wise to mine these processes for data related to the incident because there’s a good chance that one or more of them was involved.
All processes, including the system-critical ones, are running in session 0, which indicates this is an older (Windows XP or 2003) machine (that is, before session 0 isolation) and that only one user is currently logged on.
Two of the AcroRd32.exe processes have 0 threads and an invalid handle table pointer (indicated by the dashed lines). If the exit time column were displayed (we truncated it to prevent lines from wrapping on the page), you’d see that these two processes have actually terminated. They’re “stuck” in the active process list because another process has an open handle to them (see The Mis-leading Active in PsActiveProcessHead:http://mnin.blogspot.com/2011/03/mis-leading-active-in.html).
The process with PID 2280 (a[1].php) has an invalid extension for executables—it claims to be a PHP file. Furthermore, based on its creation time, it has a temporal relationship with several other processes that started during the same minute (14:19:XX), including a command shell (cmd.exe).
pstree
When viewing the processes as a tree, it’s much easier to determine the possible events that took place during the attack. You can see that firefox.exe (PID 180) was started by explorer.exe (PID 1300). This is normal—anytime you launch an application via the start menu or by double-clicking a desktop icon, the parent is Windows Explorer. It is also fairly common for browsers to create instances of Adobe Reader (AcroRd32.exe) to render PDF documents accessed via the web. The situation gets interesting when you see that AcroRd32.exe invoked a command shell (cmd.exe), which then started a[1].php.
psscan
Alternate process listings
Process object scanning: This is the pool-scanning approach discussed in Chapter 5. Remember that the pool tags it finds are nonessential; thus, they can also be manipulated to evade the scanner.
Thread scanning: Because every process must have at least one active thread, you can scan for _ETHREAD objects and then map them back to their owning process. The member used for mapping is either _ETHREAD.ThreadsProcess (Windows XP and 2003) or _ETHREAD.Tcb.Process (Windows Vista and later). Thus, even if a rootkit manipulated the process’ pool tags to hide from psscan, it would also need to go
back and modify the pool tags for all the process’ threads.
CSRSS handle table: As discussed in the critical system process descriptions, csrss.exe is involved in the creation of every process and thread (with the exception of itself and the processes that started before it). Thus, you can walk this process’ handle table, as described later in the chapter, and identify all _EPROCESS objects that way.
PspCid table: This is a special handle table located in kernel memory that stores a reference to all active process and thread objects. The PspCidTable member of the kernel debugger data structure points to the table. Two rootkit detection tools, Blacklight and IceSword, relied on the PspCid table to find hidden processes. However, the author of FUTo (see http://www.openrce.org/articles/full_view/19) proved it was still possible to hide by removing processes from the table.
Session processes: The SessionProcessLinks member of _EPROCESS associates all processes that belong to a particular user’s logon session. It’s not any harder to unlink a process from this list, as opposed to the ActiveProcessLinks list. But because live system APIs don’t depend on it, attackers rarely find value in targeting it.
Desktop threads: One of the structures discussed in Chapter 14 is the Desktop (tagDESKTOP). These structures store a list of all threads attached to each desktop, and you can easily map a thread back to its owning process.
Event Log File
Before Vista
Finding Event Log File in Memory
Extracting Event Log File in Memory
The above uses the --save-evt option, the plugin created an .evt file (raw binary event log) and a .txt file (parsed records in text format) for each log file. The output of the parsed text file is in the following format:
Logging Policies
Windows Vista, 2008, and 7 Event Logs
Logs located on the disk at
Note: To find the equivalent security IDs for Windows Vista, 2008, and 7 machines, add 4096 to the ID used for Windows XP/2003. For example, to find events that are related to someone logging on to a Windows 7 machine, the ID of interest would be 4624 instead of 528.
dumpfiles
You must extract the logs from memory using the dumpfiles plugin and then parse them with a tool external to Volatility. You can choose either a targeted methodology (finding and dumping the event log of choice) or you can choose to dump all event logs by making use of the dumpfiles plugin’s pattern matching (regular expression) capabilities.
The following shows how to investigate one of these logs with the evtxdump.pl utility from Evtxparser:
Output of the command:
Provider Name: Tells you from which log this information was extracted.
EventID: Contains the event ID that you would look up online to figure out what event transpired.
TimeCreated: A timestamp for when the event was generated.
EventRecordID: The ID of the record, which helps you figure out the ordering of the generated records.
Registry in Memory
Key information in registry:
Hardware: Enumerate the external media devices that were connected to the system.
User account information: Audit user passwords, accounts, most recently used (MRU) items, and user preferences.
Recently run programs: Determine what applications executed recently (using data from the Userassist, Shimcache, and MUICache keys).
System information: Determine system settings, installed software, and security patches that have been applied.
Malware configurations: Extract data related to malware command and control sites, paths to infected files on disk, and encryption keys (anything malicious code writes to the registry).
hivelist
The hivelist plugin scans for registry hives and then prints out their physical and virtual offsets and path information.
The following is an example:
printkey
In the output, you can see the registry path, key name, last write time, subkeys, and any values that the key has (in this case, there were none). The printkey plugin also tells you whether the registry key or its subkeys are stable (S) or volatile (V).
Detecting Malware Persistence
These keys contain information about programs that run when the system boots up or a user logs in. Therefore, you should check these known registry keys to see if the malware is using them to persist on the machine. The following list shows some known startup keys.
For system startup:
For user logons:
An example of malware persistence is shown in the following output. The malicious executable C:\WINDOWS\system32\svchosts.exe is run every time the system starts up. This is immediately suspicious because no svchosts.exe executable exists on a clean Windows machine—it is attempting to blend in with the legitimate svchost.exe (without the extra “s”). Notice that you do not have to prefix the –K/--key argument with HKLM\SOFTWARE because it is actually not part of the path within the registry, but instead denotes which registry contains the key (for example, the SOFTWARE hive on the local machine).
Network
netscan
The primary Volatility plugin for determining network connections in Windows systems beyond Windows XP is the netscan plugin. It will carve through the memory dump looking for artifacts from network activity, which means it may find sessions that were active or inactive at the time of the RAM dump.
yarascan
All web browsers optionally save a user’s browsing history in a file on disk. Before the browser process can access that information, it reads the file’s contents into RAM. Internet Explorer’s history file (index.dat) is not only loaded by the browser but it’s also loaded by all processes, including Windows Explorer and malware samples that use the WinINet API (InternetConnect, InternetReadFile, HttpSendRequest, etc.) to access HTTP, HTTPS, or FTP sites.
You can use the yarascan plugin to get an initial idea of where index.dat file mappings may exist in process memory. Because the file’s signature includes "Client UrlCache", that string will make a good starting point. This command is shown in the code that follows.
iehistory
http://www.forensicswiki.org/wiki/Internet_Explorer_History_File_Format
Starting with IE 10, the format and storage mechanism changed drastically (http://hh.diva-portal.org/smash/get/diva2:635743/FULLTEXT02.pdf).
The history data can be quite interesting. However, it can also be verbose, so you might want to try the CSV option and open it as a spreadsheet for sorting and filtering. This can be done by appending the --output=csv option to your command, as shown here:
To access the hosts file, use the filescan and dumpfiles plugins, as shown in the following commands. The first command finds the physical offset of the hosts file’s _FILE_OBJECT structure.
The second command extracts the file’s content to disk.
The next command shows the entries in the infected system’s hosts file. As a result of these entries, programs on the running machine are not able to access any popular antivirus websites or update servers.
Investigating Service Activity
Get-Service PowerShell command
sc query
Another option that you can access from a standard command shell (that is, not PowerShell) is the sc query command. The following list shows the installed services along with their types and current states:
scanning memory for services
There are a few ways to enumerate services by parsing process memory. A programmer named EiNSTeiN_ wrote a tool called Hidden Service Detector (hsd), which runs on live Windows systems. It works by scanning the memory of services.exe for PServiceRecordListHead—a symbol that points to the beginning of the doubly-linked list of _SERVICE_RECORD structures on XP and 2003 systems. In particular, hsd scans services.exe for the pattern of bytes that make up the following instructions:
Dump process from memory
This will dump the process.
This will dump the process and all of its loaded modules so you can analyse it, run strings and such. Use strings -a -t d -e l to treat everything as text.
Extract credentials from a memory dump
Last updated
