As mentioned in the previous post, this post would be about dynamic analysis of the darkcomet with sysinternals. At the end of the post, you can download the attached file with the steps of how to share a folder (read-only) between host and the guest virtual machine.
In this post we will continue with the analysis of darkcomet on windows 7 virtual machine. I hope you might have downloaded the virtual machine (of windows 7) for Virtual Box, from the link I had provided in the previous post.
I had also provided the link to deploy an existing virtual machine ( the ova file which you had downloaded from the Microsoft’s website is an existing virtual machine ) in Virtual Box. So, I am assuming the step up is ready with you.
Now it’s time for some dirty work with the malware. Let’s boot up our newly deployed virtual machine. You would need to share a folder from your host machine to your guest machine ( which would be discussed in the downloadable file ), prior to the boot up phase.
Note:Your host’s antivirus must be disabled, so that your cute little malware doesn’t get killed.
Warning: Cute malware may be a dangerous killer. Keep away from kids!!!! Hahahaha … Which means, it may infect your system … don’t change the extension ( to exe ) or double click it, in your host machine. Your system won’t be infected until you perform the above mentioned actions.
So, now our virtual machine is ready to be infected. For infecting the machine follow the below steps in sequential manner:
- In the shared folder, copy and paste the sysinternals suite, fakenet and the malware containing file.
- In the virtual machine copy and past the above shared files on the desktop. Ensure that everything is copied.
- Now disable the sharing setting of the virtual box. If a system reboot is necessary, its advised to perform the same.
- This would prevent your host system to be infected.
- Ensure that the networking is disabled, before you start the virtual machine again.
- Start the virtual machine.
- Run the fakenet as an administrator
- Now execute, double click, the executable file
- In this image, you can see that I have called up the task manager.
- In the task manager, you can observe that, the process which we discovered in the memory analysis, is running in the background.
- So, fakenet is also capturing all the packets sent from this host and would have dumped it in the same directory in which it is getting executed.
- Now, stop the fakenet and analyse the packet dump ( I would explain the analysis of packet dump in my future posts ).
Let’s focus on sysinternals suite. The first tool we would be executing is Autorun.
Note: It is preferred that you execute Autorun as Administrator.
Autorun would give us, all the information related to default start up applications, which we can see in the below figure.
In the above figure, we can observe that the process called “runddl32.exe” is being called by default and it has also created a registry key. This verifies that the program is persistent, which means it would be called in the boot up process.
Next, we need to invoke ( not the powershell one … lol ) process explorer. For using the process explorer I would recommend to enable the internet connection. For doing this we need to shutdown the virtual machine. In the settings, enable the networking and ensure that it is in bridge mode. Click apply and then ok. Fire up the Virtual Machine.
After the machine has booted up. Start the process explorer as administrator. You may see kind of similar screen, as in the below figure. In the figure you can observe that the process runddl32.exe is running behind the scene ( in backstage … lol ). Winlogon.exe is calling the suspicious process runddl.exe. As we know that, winlogon.exe is by default invoked by the windows to facilitate the logon process
Note: winlogon.exe is a part of the Windows operating system that provides interactive logon support. Winlogon is designed around an interactive logon model that consists of three parts: the Winlogon executable, a Graphical Identification and Authentication dynamic-link library (DLL) referred to as the GINA, and any number of network providers.
So, possibly, the suspicious process in using the process injection technique.
We can also find that the runddl.exe is calling the notepad.exe ( as we have observed in the memory analysis with volatility ).
Now, let’s take some help from internet and verify that our suspicions are correct. The best way to verify our findings ( related to malicious process ) is Virus Total or VT. Virus Total is a website that analyses any files and URLs to detect if those are suspicious or not ( these submissions are automatically shared with the security community ). If it is suspicious then it also displays the types of malware.
So, for taking the help of virus total, we would need to add some columns in the process explorer. For adding the columns please follow the below provided steps:
- Click on View –> Select Columns.
- You would see a window as in the above figure.
- Select / Check the options named as Verified Signer and Virus Total
- Click on OK. By doing this you have just added the columns. But to, actually, submit the signatures to Virus Total, we need to do enable some more settings.
- Click on Options –> Verify Image Signatures.
- Click on Options –> VirusTotal.com –> Check VirusTotal.com
If you have performed the steps correctly you may start seeing the scores of each process, as in the below figure.
In this figure, we can see that, runddl.exe has 60 / 61 as the Virus Total score. This score means that 60 Anti-viruses has given a confirmed result that this process s malicious.
Note: You can also generate the hash of the process and submit it in the Virus Total website. It will also be do the work.
These are very vital tools for the malware analysis. Some of the tools also support the analysis are listed below:
RAMMap would give information regarding the runddl32.exe ‘s mapping address of logical and physical memory.
Using TCPView, we can observe the connection made by all the processes. As we can see that runddl32.exe has made an outbound connection ( using the TCP port number 49500 ) with the IP address 184.108.40.206 ( having TCP port number 1604 ), which is weird. Because it’s very rare that, a process would use high range port for communication ( except the client application like web browsers and all ). If we check the IP address for IP location and blacklisting, then we might find some clue of it’s origin and the reason it was born.
So, now I am wrapping up with malware / memory analysis. I hope you enjoyed this journey ( of malware / memory analysis ). I would be back with log analysis in the next post. Stay Tuned !!!!
One thought on “Incident Response: Methodology and Case Study – Part III”
Comments are closed.