Performing malware forensics

Now that we have the fundamentals in place, it is important to understand that malware forensics is different from malware analysis. Malware analysis involves capturing a sample of the malware and performing a static or dynamic analysis on it. Here, the compiled and obfuscated code is reversed in order to try and determine what the malware was programmed to do.

Malware forensics, on other hand, attempts to locate and examine the forensic artifacts that exist on system media, RAM, and network to help answer whether the system was compromised, how was it done, what was the infection vector, which particular malware was involved, what data is exfiltrated, and so on.

In the previous section, we looked at the IOC and how they help in identifying whether a system or network has been compromised. While this helps in cases where the compromise has been caused by known malware; for zero day or yet unknown malware or its variants, a malware forensic investigation needs to be launched.

The first indicator of a malware infection is some kind of anomalous behavior. The moment this is reported, an alert administrator gets the system checked with an updated malware detection program such as malware bytes or tools such as YARA with the known IOCs. In the event the behavior persists and no positive detection occurs, it becomes imperative to perform an in-depth malware forensic investigation.

The key element to remember when we perform forensics on a malware-affected machine is to look and acquire all the available data in reducing order of volatility. This means that we need to look at grabbing RAM, all the relevant network logs, as well as an image of the hard drive. Further, we need to closely monitor all the traffic to and from the affected system.

Let's take a look at the process that we need to follow in order to conduct an effective investigation:

  • Examine the Master Boot Record (MBR): This is usually the first sector of a hard drive and has the size of 512 bytes. In the constant fight between malware and anti-malware, the struggle is to ensure who loads up first. In the event the malware makes it first, it can prevent the anti-malware from detecting it in anyway. This is where the MBR comes into play. Whenever a computer boots up, the first piece of code that gets executed is the boot code in this sector. If the malware manages to modify this to its benefit, anti-malware will fail in its task and the malware will remain resident at all times. In this case, it helps if we have a copy of the expected baselined MBR.
  • ID the operating system: Once this has been adequately done, the service packs and patches identified, then it becomes easy to download the known file hashes (from National Institute of Standards and Technology (NIST)/Hashkeeper) to enable the investigator to eliminate known good files from the investigation. Conversely, it becomes really easy to identify files whose MD5 hashes are different from what they should be and these could be the potentially infected or modified files.
  • Examine the RAM: If we have grabbed the volatile memory as discussed in the earlier chapters, we should proceed to examine the system RAM image in an offline manner. Alternatively, a live RAM analysis can be performed; however, it should be noted that this is at the risk of compromising the volatile data as every bit of activity that we perform on a system impacts the volatile memory. Volatile memory forensics is actually a vast standalone field related to digital forensics; however, from our understanding perspective, we will look at it in a simplified manner. An examination of the volatile memory can reveal the following:
    • Currently running processes (malware active in the RAM)
    • Hidden processes
    • Recently terminated processes
    • Open files (for example, files being accessed by the malware)
    • Registry handles being accessed
    • Network connections (volatile memory has more reliable information than the one obtained by running commands, such as netstat whose output may have been compromised by the malware)
    • Listening ports
    • Cryptographic keys and passwords
    • Whole files
    • File fragments
    • Keyword searchable unencrypted content
    • Hidden data
    • Malicious code (fileless malware)
  • Examine and hash files on disk: Volatile memory analysis shows us files that are in use or opened by the malware. This leads us to locating them on disk and examining them in great detail. This is greatly useful in identifying where the malware is collecting the data for exfiltration. Files identified as in use by the malware can be hashed and the suspicious files can be sent to online malware identification portals, such as VirusTotal, and hash values can be checked with National Software Reference Library (NSRL) at http://www.hashsets.com/nsrl/search/.
  • Examine the registry: Look in the autostart locations, any program in multiple autostart locations should be a suspect. Malware tends to identify and place itself or its different variants in multiple autostart locations with the objective of increasing its persistence.
  • Examine the programs run on the system: Identify what each program does and ask are the programs for performing a legitimate task? Unidentified programs need looking into in more detail.
  • Examine the system logs: Look for things that look out of place. Identify out-going connections.
  • Examine Web browsing history: This could help in identifying whether the user has visited known compromised sites as well as identify locations from where a drive by the download has occurred.
  • Examine file artifacts: Especially in the downloads and temporary folders, this may help in identifying the malware entry point. Also look for deleted files; malware may delete files that it no longer needs just to cover its tracks.
  • Build a timeline: Plot all the activities gleaned from file dates, e-mails, web visits, cookies, logs and so on to try and build a sequence of events. Files that appear on your timeline within the period that you suspect the system was compromised definitely require a second look.
  • Re-examine everything.

Once this is done, it is worth loading the allegedly compromised system in a virtual environment and examining all the activities performed by it. Its interaction with the network and the consequent changes in the previously baselined system will definitely be noteworthy and a further forensic examination along the previous lines could be conducted in order to gather more information about the malware and its activities.

Once the malware and its IOC have been determined, the IOCs can be added to various perimeter devices in order to prevent the recurrence of the malware on the network.

Malware insight – Gameover Zeus Trojan

The Gameover Zeus Trojan has been one of the most successful malware of all time. Like most malware, it all begins with an innocuous spam e-mail, which leads to an infection that, in turn, results in an account takeover, followed by the fraud. The money is transferred out of the bank account and to prevent its timely discovery, the bank or financial institution is subjected to a distributed denial-of-service (DDoS) attack. This attack causes all the security resources of the bank to be focused on tackling the DDoS and it also allows the attackers to fill the logs with so much DDoS-related data that the investigators are likely to miss or altogether lose the information relating to the financial theft. In the meantime, the money is withdrawn and effectively laundered.

Zeus began its career as a malware kit in 2005 and Zeus version 2 was launched in 2009. However, in 2011, the Zeus source code was made public and some really talented software programmers went on to refine it into a number of variants. One of the variants added the peer-to-peer (P2P) protocol and Gameover Zeus was born. Prior to this, there were centralized command and control servers and this made them the targets of law enforcement and anti-malware researchers.

Sophisticated peer-to-peer capabilities have really empowered the Zeus malware, decentralizing the command and control structure as well as helping in creating a botnet with the infected computers aware of nearby peers, with daily configuration updates, and weekly binary updates via the command and control channels. This lack of a single point of failure makes Gameover Zeus botnet very resilient.

P2P Zeus or Gameover Zeus is a malware targeting bank credentials and is capable of causing considerable financial losses. It harvests banking information, infects systems to join the botnet, sends out spam, is also known to deliver other malware such as CryptoLocker, and can participate in DDoS attacks. It modifies the registry and infects the explorer.exe and other processes. Once resident in memory, it stays dormant until a web page belonging to a financial institution is accessed, where it injects additional fields and pop-ups to steal user credentials.

Forensic artifacts left by the Gameover Zeus malware include information in the volatile memory, system logs, as well as system registry.

An example of a forensic artifact that can be found in the case of this malware is a modification in the following registry key causing the disabling of the firewall:

HKLMSystemControlset002ServicesSharedAccessParametersFirewallPolicyStandardProfileEnableFirewall

The malware sets the value to 0, disabling the firewall and reducing the chances of its detection.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
52.15.148.187