Skip to main content

Malware Analysis Using Volatility - Part 6

PRACTICAL LIVE ANALYSIS AND AUDITING USING REDLINE IOC MODELS

What is our challenge in a real case?

Our discussion on Redline usage will be divided into two parts. In the first part, presented in this
article, we will cover a basic introduction to Redline. In the second part, which will be published in a later issue, we will deal with the IOC Models call methodology.

The diversity of malware infections today presents us with a variety of forensic tools to analyze malicious code. Considering classic advice given by Farmer and Venema (2005), whether the tools we use are open source or commercial tools, we must not only understand the usability of each tool but also understand how these tools collect the data to be analyzed by the forensic expert. Two issues emerge from that:

      a) What is the quality of the data returned by these tools?

      b) What impact do the tools have on the data?

Starting from a very basic idea, we decided that every tool will have its advantages and disadvantages when used in a real forensic problem, depending on what this problem is and the specific tools used. So we do not claim one forensic tool is better than another, we are far from it. We should use all the tools available, but we adapt better to certain tools (perhaps because there is larger than usual availability of use, etc.). In fact, it does not matter much because we can one day face a forensic case in which we cannot use any tools! And that day will depend on our programming ability to develop a forensic script or a complete tool for our own use.

 "Which tool is better?" always the answer is: all are better and none are better. All tools can be excellent and all can be unusual. The correct answer will depend on each case. In the forensic battlefield, the choice of a tool does not necessarily depend on personal preference of the expert or his ability to work with this tool, but depends most importantly on whether the answer returned by that tool to the expert has the quality to solve the investigated problem.

In light of all the forensic problems that we face every day, most involve cases in the Windows environment and in situations where the machine cannot be turned off for analysis. In this scenario, the only possibility is to capture the data with the machine running because the company that owns the machine informed us that it needed the machines in operation to complete all payments of its employees. Thus, the option we had to take was to conduct a live analysis.

Using Redline 1.14 to Audit a machine

If our main goal is to audit a machine using an image extracted from its memory, Redline becomes an interesting option for us to build a response to an incident. Redline is a free tool developed by FireEye with a set of scripts adaptable to expert needs.

Assuming that this is a basic tutorial about Redline, we show that the Redline tool can collect and analyze data according to some scripts. But an important feature of Redline is the creation of statistical risk score. The expert can rate every piece of evidence from these scores.

According to the Redline User Guide (see p. 7):

A. The Standard Collector configures scripts to gather the minimum amount of time to complete an
     analysis and generate Malware Risk Index (MRI).

B. The Comprehensive Collector configures scripts to gather most of the data that Redline collects
     and analyzes. Use this type of Redline Collector if you intend to do a full analysis or if you have
     only one opportunity to collect data from a computer.

C. The IOC Search Collector collects data that matches selected Indicators of Compromise (IOCs).
     Use this Redline Collector type when you are looking only for IOC hits and not any other potential compromises. By default, it filters out any data that does not match an IOC, but you can opt to collect additional data. If you do not use an IOC Search Collector, you can still analyze data collected with IOCs after the data has been imported into Redline to create an analysis session. The effectiveness of the IOC analysis depends on the data available in the analysis session.

For the purpose of this article, we have selected the first option and we have prepared a memory image of an Asus notebook with an Intel Core i5 processor with 2.5 GHz and RAM 6GB, running the Windows 10 operating system. The machine operates constantly, being used for sensitive customer data analysis and collecting information on Data Mining models.

Using the tool

First, we prepare a storage location for the data that will be collected by the tool. Below shows that we are storing the data in a directory called redline with patch


C:\Users\paulo_000\Contacts\Desktop\FORENSE REDLINE\redline (Figures 1 and 2 - detail).

























Figure 1: Preparing a directory to receive the data generated by the Redline Standard Collector script to collect a minimum amount of data.








Figure 2: In detail, the directory that will receive the files generated by Redline.






Figure 3: In detail the “Edit your script” option that can be configured to capture a minimum or a maximum amount of data from a machine.

The software also enables the forensic expert to edit the script that will collect the information on the machine to be investigated. Below, we can see that there are advanced options for the collection of evidence that may be edited, depending on each case. The options include the collection of evidence in the memory, disk, system, network, and other options, if needed (see Figures 4-8). The choice of all options can slow the catch, depending on the machine on which the Redline is running. Another point to note is that by opting for analysis with advanced features, the forensic expert should have some previously available information about a process that will be specifically analyzed.
































































































































After you select the options, the script will be generated, then just click "OK" and proceed to prepare the tool to collect evidence. Redline created a package called "Collector" (Figures 9-11).












































The RunRedlineAudit is a .bat file for Windows forensics purpose analysis that can be stored in external USB drive and on a machine that will be investigated. Simply insert the USB drive into a port and run the .bat file. However, nothing prevents the same machine on which the Redline was installed from being analyzed. Simply turn the option “Analyze this Computer” (Figure 12). The .bat file can be saved and run. The same previous above mentioned options can be configured, assuming the forensic analyst opts for direct analysis of the machine; just set the options available and start collecting evidence. In this case, the data collected will be stored in a directory chosen automatically by the software and the result file is named AnalysisSession1, but those can be changed by the analyst.
























We can summarize this whole process of evidence collection using Diagram 1 below: we generate the Redline collector on a flash drive on a machine that is not infected. Connect the USB to a potentially infected machine, collect data according to the configuration chosen in the script and analyze the evidence in uninfected machine.






















After all the settings have been chosen, the analysis starting time was 13:19:24. For this analysis, we chose the all options available in the five categories: memory, disk, system, network and other. This may take a long time, depending on the machine hardware. After this stage, we are able to audit the machine in question as shown below.













































Understanding and using the IOC

Redline introduces two key concepts for the forensic analysis of malware. The first is a risk indicator called Malware Risk Indicator (MRI). The second is Commitment Indicator or Indicators of Compromise (IOCs). The MRI is based on the probability of an event in normal circumstances. For example, we know that malware can trigger some functionality of a system remotely. In this case, would it be normal for a Windows process that could not be started from the command line to suddenly be ordered from the command line? The MRI algorithm to calculate a score assuming that an abnormal event occurred has a score above 100 (high risk). Lower scores, of course, are classified as low risk. Assuming that "it is unlikely that the named memory section imported into many processes is malware, whereas it is more likely that the named memory section imported into only one process is malware", the Redline algorithm calculates the probability that a malicious event occurs.

This works with a substitutive methodology of analysis by signatures. The power of this approach lies in the fact that the expert can combine multiple forensic artifacts it considers suspicious, such as, for example, a cookie, a super cookie, a malicious domain or a Windows service, for which a malware has injected malicious code. In the figure below, for example, an IOC is created for the purpose of investigation of an executable called uddi32.exe and lsass.exe.















Depending on the need of the researcher, he can create his own decision tree (see below) to match solutions to their audit.

This will be discussed in an upcoming article. Since this article mainly discussed the proposal for an analysis through the use of the IOC (Commitment Indicators) and the logical composition of a combination of a simple argument for a complex argument, the next article aims to address a more complex forensic investigation using a machine infected by malicious code that affects Windows 10, making the bypass SmartScreen filter, and compromising a critical process system. We'll show how to build a logical argument to a complex combination of IOC.




















Redline and Volatility

We do not use both software as a counterpoint to each other, but we recommend the joint and combined use of the two tools. However, memory is a task that both capture. Using version 2.5 Volatility (standalone), it is observed that there is a considerable delay for the image profile (we tested a Dell machine with 6GB of memory and a virtual machine with 2 GB of memory). Both machines were running Windows 10 (x64). The first observation to be made is the time that it took Volatility to identify a profile: more than an hour in both cases. Version 2.5 adds support for Windows 10 as the description that is on the site that hosts the releases of the framework. The comparison between the two software will be in another article when we use malware and seek evidence in both tools.

Popular posts from this blog

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 payload in the server.  Let’s e

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

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