Incident Response: Methodology and Case Study – Part II

In this article, I will continue with the memory / malware analysis which have been started in the previous post. At the end of the post, you will be able to download a Volatility cheat sheet along with a document related to Sysinternals.

Till now we found the following:

  • A suspicious process, named “runddl32.exe”.

When we checked for the path, it wasn’t in the System32 folder. It was getting executed from the temp folder (MSDCSD, created by the malware).

There were other processes like cmd.exe and notepad.exe accompanying the runddl32.exe (we would analyse the chain of events also)

We also found that, it was calling many Windows APIs (which we would analyse in the next post)

Windows defender says it as a backdoor named “Fynloski.A”

When I checked “Fynloski.A” in google, I landed up in the following link: –

https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=Backdoor:Win32/Fynloski.A

This goes my many aliases: W32/Fynloski.Q (Norman) BDS/Bancodor.A (Avira) BackDoor.Comet.origin (Dr.Web) Backdoor.Win32.Bancodor (Ikarus) Backdoor.Badcodor (Symantec) BKDR_COMDAR.SMI (Trend Micro)

It says that it is a backdoor and This threat can create a mutex on your PC.

For example:

DC_MUTEX-SWNQ6GE

It might use this mutex as an infection marker to prevent more than one copy of the threat running on your PC.

So, let’s use of favourite memory analysis tool, Volatility, to check this mutex and verify if it’s really the DarkComet.

volatility -f WIN-TTUMF6EI3O3-20140203-123134.raw mutantscan
Fig 1 : Volatility Mutex Scan

If you verify, you would find that this was in the process named “runddl32.exe”.

As we have confirmed that, it has DC_MUTEX in the registry (created by the process), we can conclude that it is DarkComet at its best.

If you have downloaded the reports.7z file, then you have already downloaded the malware. So, let’s uncover the file which posses as a legitimate file, but it is a malware. Okay, for performing this activity, we need to take a walk. Hahahaha!!!

Don’t start walking, I was talking about binwalk. Binwalk is a great tool for analysis a file, According to Kali’s definition:

“Binwalk is a tool for searching a given binary image for embedded files and executable code. Specifically, it is designed for identifying files and code embedded inside of firmware images. Binwalk uses the libmagic library, so it is compatible with magic signatures created for the Unix file utility. Binwalk also includes a custom magic signature file which contains improved signatures for files that are commonly found in firmware images such as compressed/archived files, firmware headers, Linux kernels, bootloaders, filesystems, etc.”

For analysis the file using binwalk, we would need to use the following command on the files (which is in the out directory compressed within the reports.7z): –

binwalk <file_name>

When I applied this on every file in the directory, a file caught my interest.

Fig 2 : Binwalk analysis

According to the result, I found out that, file.1524.0x84fff6b8.dat has an exe (PE, Potable Executable) embedded in it.

We can also check this in Hex format using the hexdump.

Fig 3 : Hexdump Analysis

As in the above image, if the first four character is 5a4d or 4d5a, then this file is a PE. You can get the other file type’s hex header here.

Fig 4 : Hexdump for a PE

Let’s go back to volatility and check what other things are suspicious.

If we remember, there was two other process that was called by the runddl32.exe, one was notepad.exe and the other was cmd.exe.

Fig 5 : Pslist for notepad.exe

From the image we identify that notepad.exe was called by runddl32.exe, as the parent process ID of notepad.exe is 1524; which is the process ID of runddl32.exe.

So, lets check if we find, why was notepad.exe called by runddl32.exe.

For this purpose, also, we would need volatility. The plugin we would use now would be the malfind.

volatility -f WIN-TTUMF6EI3O3-20140203-123134.raw --profile=Win7SP1x86_23418 malfind
Fig 6 : Volatility Malfind

This would give you a much-detailed information about what is going on in the assembly level. Here we can see which variable is moved, which process is call which API, etc.

Now, let’s see why notepad.exe was called.

Fig 7 : Volatility Malfind

Here, we can see that sleep function was called by notepad.exe, which is weird.

Fig 8 : Volatility Malfind

In this we can see that CreateProcess was also called, suspicious.

Fig 9 : Volatility Malfind

In the above figure we can see that CreateMutex was called.

Fig 10 : Volatility Malfind

And in this we can see that it has created DC-MUTEX, which we found in mutant scan.

Now let’s run this file in a Windows 7 virtual machine and observe its behavior in a virtual environment.

Note: Microsoft has removed the Windows 7 VMs, hence, please use the following links to download:

The link which I have provided to download the Windows 7 machine, is a pre-installed windows 7 machine which is provided by Microsoft and it is valid for 90 days, once you have deployed it and started the virtual machine.

Note: – I have selected windows 7 machine since, windows 10 uses a service called “Anti-malware Service Executable” which stops malicious application to execute in the first place.

As we have located the malicious file, now we just need to transfer the file into the virtual machine (for doing a dynamic analysis of the malware).

Note: – I am using VirtualBox as it is an open-source software.

If you have downloaded the virtual machine (for Virtual Box) from the provided link then, you would get compressed zip file (of 5 GB approx.). When you unzip it, it would contain an ova file. You would just need to import the ova file by doing the steps as mentioned in the link.

Once the appliance is imported then, fire up the appliance (Don’t literally fire it up !!! Else you would have to use fire extinguisher…. lol) and check if it is booting up normally. Now shutdown your virtual machine. After it has ceased, click on the settings button (in the Virtual Box) and navigate to the shared folders option. Share a folder in read only mode, so that, the virtual system doesn’t infect your host system. Click ok and copy the Sysinternals Suite.

Oops!!! I forgot to describe the Sysinternals Suite. So, let’s study Sysinternals in this post and I would describe how to use it in the next post (this is not the complete set of Sysinternals, remaining is in the document). Sysinternals Suite is a collection of tools provided by Microsoft, defined as: –

The Sysinternals Troubleshooting Utilities have been rolled up into a single Suite of tools. This file contains the individual troubleshooting tools and help files. It does not contain non-troubleshooting tools like the BSOD Screen Saver.

Referencehttps://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite

Stay tuned for the upcoming dynamic malware analysis.

Download the cheat sheet from here and document for Sysinternals suite

One thought on “Incident Response: Methodology and Case Study – Part II

Comments are closed.