Skip to main content

Malware Analysis Using Volatility - Part 1

Malware Analysis with Volatility Module 1

➡ How do you capture the image memory of a machine through the use of different
     tools

➡ Software Imager Lite 3.1.1 (FTK), Ram Capturer 1.0 (Belkasoft) and Dumpit 1.3.2
     (Moonsols).

➡ How to configure your computer environment to use the Volatility.

➡ And the basic use of imageinfo, kdbgscan, pslist, pstree and psscan plugins in the
     Volatility (version 2.5).

Memory tools for Live Analysis

 First let's start with the RAM capture tools. In a modern school of live analysis a forensic analyst should have more than one tool at your disposal.

Will show the use of memory tools for live analysis.

The tools and the file format

 Imager Lite

     ➡ The Imager Lite captures the RAM and saved in a memdump.mem file.

    ➡ The Imager doesn't need to be installed on the machine.

Dumpit

     ➡ The Dumpit saved the output in a PAULO-PC 20160617-213817.raw file.

RAM Capturer

    ➡ The RAM Capturer saved the output in a 20160617.mem file.

Comparison of the VMs

 VirtualBox

     ➡ The VirtualBox doesn´t save a memory dump when we suspend the virtual machine.

VMware

 ➡ The Vmware saves a memory dump when we suspend the virtual machine (format .vmem)

Configuring an environment to use Volatility

 The essential question for working with the Volatility in a Windows environment is the fact that it runs from the Command Prompt. So, the shorter our command, the chance of error will be smaller. For example, if I decide to work in a folder located on my Desktop the command would be:

C:\Users\paulo_000\Contacts\Desktop\Module1\vol>vol.exe imageinfo -f img1.mem

This command is too long and boring…

If we decide to work, for example, with a folder named "vol" on drive C, our command would be:

C:\vol > vol.exe imageinfo -f img1.mem

You can also extract the result to a txt file :

C:\vol > vol.exe imageinfo -f img1.mem > imageinfo.txt

Using Volatility: Profiles

 When we acquire a memory sample from a machine we need to know the profile of operating system running in the machine to analyze the data structures, algorithms and symbols.

By default Volatility uses the approach of the similarity of Windows operating systems architectures. So, it is normal Volatility indicate more than one OS profile to use. Based on this approach and in the Service Pack version we can choose one profile and use it.

In some cases Volatility will not display a profile. So tested this situation with memory samples taken from the W10x64, for example.

In Linux OS the similarity approach doesn’t work because there are a large number of kernel version (and subkernel versions). In this case we must build a profile. See [1] for more details.

When we don’t know the profile of the memory sample, the basic usage of Volatility starts with the imageinfo command to discovery the profile of a memory sample. This command shows only the profile, if there is one associated with the KDBG (Kernel Debugger data block).

Using Volatility: Imageinfo plugin

 The command kdbgscan shows more information about the memory sample image. Since we have a profile, we can use it for other plugins.

Using Volatility: Default profile

 Volatility uses WinXPSP2x86 as the default profile. We don’t need to specify a profile in this case.


Popular posts from this blog

Haking On Demand_WireShark - Part 5

Detect/Analyze Scanning Traffic Using Wireshark “Wireshark”, the world’s most popular Network Protocol Analyzer is a multipurpose tool. It can be used as a Packet Sniffer, Network Analyser, Protocol Analyser & Forensic tool. Through this article my focus is on how to use Wireshark to detect/analyze any scanning & suspect traffic. Let’s start with Scanning first. As a thief studies surroundings before stealing something from a target, similarly attackers or hackers also perform foot printing and scanning before the actual attack. In this phase, they want to collect all possible information about the target so that they can plan their attack accordingly. If we talk about scanning here they want to collect details like: • Which IP addresses are in use? • Which port/services are active on those IPs? • Which platform (Operating System) is in use? • What are the vulnerabilities & other similar kinds of information. • Now moving to some popular scan methods and ho...
Read more

Bypassing Web Application Firewall Part - 2

WAF Bypassing with SQL Injection HTTP Parameter Pollution & Encoding Techniques HTTP Parameter Pollution is an attack where we have the ability to override or add HTTP GET/POST parameters by injecting string delimiters. HPP can be distinguished in two categories, client-side and server-side, and the exploitation of HPP can result in the following outcomes:  •Override existing hardcoded HTTP parameters  •Modify the application behaviors   •Access and potentially exploit uncontrollable variables  • Bypass input validation checkpoints and WAF rules HTTP Parameter Pollution – HPP   WAFs, which is the topic of interest, many times perform query string parsing before applying the filters to this string. This may result in the execution of a payload that an HTTP request can carry. Some WAFs analyze only one parameter from the string of the request, most of the times the first or the last, which may result in a bypass of the WAF filters, and execution of the pa...
Read more

Bypassing Web Application Firewall Part - 4

Securing WAF and Conclusion DOM Based XSS DOM based XSS is another type of XSS that is also used widely, and we didn’t discuss it in module 3. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie, and it is also a security feature that limits scripts on different domains from obtaining cookies for other domains. Now, the XSS attacks based on this is when the payload that we inject is executed as a result of modifying the DOM environment in the victim’s browser, so that the code runs in an unexpected way. By this we mean that in contrast with the other two attacks, here the page that the victim sees does not change, but the injected code is executed differently because of the modifications that have been done in the DOM environment, that we said earlier. In the other XSS attacks, we saw the injected code was ...
Read more