Forensics

Malware – Domain Generation Algorithm (DGA)

Ask anyone in the incident response community and they will tell you the malware analysis is becoming a large part of their day-to-day activities. Malware seems to be everywhere and they are getting smarter and more effective. Generally malware behave predictably, they infect the system, drop files, make changes to the registry settings to be persistent, connect back to command and control (C&C) server and perform exfiltration activities on the system by stealing confidential data. The malware analysis process provides in-depth information on such activities. Once a understanding is achieved on the activities of a particular piece of malware organizations can then take necessary actions to protect their networks.  Steps taken include blocking the malicious IPs being used by the malware and also by creating the indicators of compromise (IOCs) to help further in the forensics and incident response activities.

Here is an example of a recent investigation we performed.   A user received a phishing email with an attached Word document file.

malware1
malware1

The user not only opened up the email but also clicked on the attachment to view the document. Once our team was alerted we began the triage process.  We captured the malware sample from the infected system and brought it to our lab for analysis.

The lab environment includes a system running with Cuckoos sandbox, the malware sample was uploaded and the report was generated. The Cuckoo sandbox report is divided into the following sections:

  • Quick overview
  • Static analysis
  • Behavior analysis
  • Network analysis
  • Dropped files

The sandbox analysis of a malware sample provided a lot of information on the design and function of this piece of malware. However, this type of analysis does not always provide the most comprehensive and in-depth analysis.  The real fun begins when we actually executed the malware in a virtual machine and sent all the traffic to a DNS sinkhole.

For DNS sinkhole we installed and setup the FaketNet tool that helps in the dynamic analysis of the malicious software. This tool simulates a network and captures the traffic generated by the malicious software/malware.  The tool is highly configurable and by default it listens to and captures the traffic on port 80 as well as on DNS port 53. The following screenshot of FakeDNS tool shows the traffic generated by the examined malware which is trying to connect to IP addresses that were hard-coded in the malware for C&C server.

malware2
malware2

So far the behavior of the malware was as expected, it was trying to make connection to the C&C server.  This is nothing out of the ordinary for malware. We let it run for a while, but then we observed something we have not seen before, the FakeNet was showing connection attempts to some strange domain with random long names and there were numerous variations and requests.

malware3
malware3

FakeNet also generates a PCAP file; we opened the file in WireShark and filtered for DNS traffic and it shows all the connection attempts made to the random domains. The malware was intelligent, first connecting to bing.com to ensure network connectivity.

malware4
malware4

The question is why there were so many randomly generated domain names?  A little research revealed that it is because of domain generation algorithm (DGA). Malcious hackers have incorporated this algorithm into their malware to counter the network blocking devices where the static C&C IP addresses and domain names are being blocked by the organizations and law enforcement officials.

The new breed of malware with DGA periodically generates these domain names and waits for when the C&C responds backs.  But how does a hacker know which domain names he should register out of so many? The answer is, hackers are aware of the pattern in the algorithm and know exactly which domains are being generated once the malware is executed. In order to have a successful connection to C&C the malware must have one or two of these randomly generated domain registered, as soon as that registered DNS name is generated by the malware using DGA, the connection is established to C&C .

At this point in time there is not one comprehensive enterprise solution in available that detects and prevents against this type of sneaky and very clever way of circumventing the static blocking of IPs and domains used by the malware. Hopefully this post gives you an idea of what you can look for when examining malware.

Volatility – Memory Analysis Tool

I have recently been involved in performing forensic analysis on systems which are compromised with malware. Once a system is compromised by malicious code, there are a multitude of indicators of compromise (IOC) ranging from unusual network traffic patterns as reported by the intrusion detection and prevention systems (IDS/IPS) to the system behaving erratically which in some cases prompts the affected user to complain about it. Following the established protocols, an image of the system’s hard disk and physical memory must be taken using imaging tools.  FTK Imager Lite is one of the many tools that are available to take image dumps. For volatile memory imaging, I personally prefer to use FDPro from HBGary. The free version of this memory imaging software can be downloaded from here.

An analysis of the memory image of a workstation provides useful information about the malware that has infected a system. It is an effective way to analyze the behavior of malware while it is running on the system. Such analysis provides information about DLL injections, open connections to malicious IPs and domain, running processes in the system at the time of infection, etc. In the following examples, I downloaded a sample VM memory image of a computer which is known to be infected with Zeus malware. I am using Backtrack 5 with Volatility to do basic memory image analysis.

First thing we need to find out is what operating system this memory image belongs to. In order to do that I need to run the following command using Volatility:

./vol.py –f ~/Desktop/zeus.vmem imageinfo

imageinfo
imageinfo

As it is clear from the result of this command, the image came from Windows XP machine with SP 2. There is a number of other information which also gets produced as a result of running this command, but for the sake of this blog we are only concern with the profile information which is showing as “WinXPSP3x86”.

Now that we know the profile of the machine, the next step is to find out how many processes were running on the system at the time of capturing the memory image. To do that we need to run the following command:

./vol.py –f ~/Desktop/zeus.mem pslist

pslist
pslist

Looking at the resultant list of processes, nothing seems to look out of the ordinary. All running processes seem to be legitimate, but we know that malwares are designed to be intelligent enough to hide themselves under legitimate processes. To accommodate that we can run another Volatility command which will produce results by comparing and displaying various methods to view the list of running processes in a system.

pxsview
pxsview

./vol.py –f ~/Desktop/zeus.mem psxview

If any of the listed methods (pslist, psscan, thrdproc, pspcdid, csrss) shows any process as false, it is a strong indication that a process is trying to hide itself.

Since we know that malware mostly have a command and control structure, once they infect a system they need to connect back to the command center. Knowing that, we now need to look at the network connections established by the malware. We can find out about any established connections by using Volatility on our memory image:

./vol.py –f ~/Desktop/zeus.mem connscan

connscan
connscan

The result of the “connscan” command shows that 2 connections were established by the infected system to a remote IP address “193.104.41.75” on port “80”. Another critical piece of information that this command revealed is the process ID “856” under the PID column, which shows the process that established the remote connection. Look back at our screenshots for psscan and psxview, we now know that PID 856 belongs to the “svchost.exe” process which is a clear indication that the rogue process is hiding itself under “svchost.exe”. To further our investigation, we need to find as much information as we can about the IP address that the system has established the connection with. A quick search on cent.robtex.com reveals that this IP address has already been black listed on the Internet.

robtex
robtex

We also wanted to know the origin of the IP address so we used an online IP geolocation service and found out that the IP is located in Moldova.

goelocation
goelocation

All of the above is great, but now we need to step a little further and investigate what else this malware has done to the system, such as what files it has created and if any code has been injected. We need to run the “malfind” command and dump the output into a directory.

./vol.py –f ~/Desktop/zeus.mem malfind –dump-dir ~Desktop/malfind |more

malfind
malfind
malfindpid632
malfindpid632
malfindpid856
malfindpid856

The output of this command shows various PIDs that were infected; we can also see PID ID 856 which we discovered earlier during our network connection investigation. The output of the “malfind” command resulted in a large number of individual dump files of the various processes that were infected by the malware.

dump-files
dump-files

To verify infected processes, we can upload them to an online virus analysis service. I uploaded one of the process dumps from the “malfind’ command to www.virustotal.com and it came back with the following analysis:

virustotal
virustotal

Virustotal shows that 27/44 of virus scanners detected and confirmed that the uploaded process dump is the Zbot/Zeus virus. The above process is a demonstration of only a basic analysis of a memory image for malware. Volatility provides a ton of other features that can help a user perform advanced memory analysis as well as recover sensitive information from the memory, such as passwords and in certain cases cryptography keys.

References: https://www.volatilesystems.com/default/volatility http://code.google.com/p/volatility/wiki/CommandReference http://code.google.com/p/volatility/wiki/SampleMemoryImages

Rehan Bashir