CyberDefenders: Ramnit (Memory Forensic Analysis)

It’s been a while since my last blog entry here. I’ve finally been able to catch up with life after returning from deployment. I would also like to take this opportunity to thank all the men and women I got to rub shoulders with, sacrificing their time to serve their country and their fellowmen. You know who you are; our shared memories will always be remembered, “No Byte, No Fight!!”

This Blue Team challenge was published on February 02, 2024 (we were still enjoying the black molds in our tent, lol) on CyberDefenders.org. You can access the challenge at https://cyberdefenders.org/blueteam-ctf-challenges/ramnit/. I completed the challenge on June 09, 2024.

I am rating this one as Easy in difficulty. If you have done any memory forensic analysis before, you should complete this in less than 20 minutes. I used REMnux as my analysis workstation, and the tools Volatility, Whois, Exiftool, and VirusTotal.

Scenario: The intrusion detection system has alerted us of suspicious behavior on a workstation, pointing to a likely malware intrusion. A memory dump of the system has been taken for analysis. Your task is to analyze the dump, trace the malware’s actions, and report key findings. This analysis is critical in understanding the breach and preventing further compromise.

1. We need to identify the process responsible for this suspicious behavior. What is the name of the suspicious process?
   • C**********.***
   • Let us quickly look at the list of processes that were running on the infected workstation during the time of the incident. We can do this by typing vol3 -f memory.dmp windows.pslist
   • Just listing the processes makes identifying which one is suspicious difficult because all the filenames appear legitimate. To help us in identifying the suspicious process, we need to look at the parent process. By analyzing the parent-child process relationship, we should be able to spot which abnormal process spawned from another process. Let’s run the command vol3 -f memory.dmp windows.pstree
   • A single asterisk * (parent process) followed by two asterisks ** (child process or processes) denotes the parent-child process. And three asterisks *** mean grandchild process. Now that we have the process tree, we should be able to identify which process is out of place or out of the ordinary.
   • 1 – is the parent process, userinit.exe. This is a key process in the Windows operating system that launches on startup. 2 – is the child process, explorer.exe. We are all familiar with this process. 3 – now, when you look at the four grandchildren process, the three have something in common, they usually startup when a VM with Windows as the guest OS boots up. The fourth one, the filename, gives it away. A normally only executed file once seems to be grouped with startup processes.
2. To eradicate the malware, what is the exact file path of the process executable?
   • C:\*****\****\*********\***********.***
   • Using the name of the suspicious executable we retrieved in question 1, we can run the filescan plugin to get the location of the file. Type vol3 -f memory.dmp windows.filescan | grep “Enter_the_name_of_the_suspicious_process_here”
3. Identifying network connections is crucial for understanding the malware’s communication strategy. What is the IP address it attempted to connect to?
   • **.**.***.***
   • We can list the network connection associated with the suspicious process by typing vol3 -f memory.dmp windows.netscan | grep “4628”
   • The 4628 above is the process ID of the suspicious process. If we don’t filter the results using grep, we will be presented with a long list of network connections. I also want to capture a screenshot of the command I used and the result of running it.
4. To pinpoint the geographical origin of the attack, which city is associated with the IP address the malware communicated with?
   • H*** ****
   • Use the IP address that we found from question number 3 and run whois. Type whois IP_address.
5. Hashes provide a unique identifier for files, aiding in detecting similar threats across machines. What is the SHA1 hash of the malware’s executable?
   • 2***************************************
   • This is a two-step process to get the SHA1 hash. First, we have to dump the suspicious process using its PID so we can retrieve the file itself. Type vol3 -f memory.dmp -o . windows.dumpfiles –pid 4628
   • I highlighted the filename. Second step, generate the hash value of the file by typing sha1sum file.0xca82b85325a0.0xca82b7e06c80.ImageSectionObject.***********.exe.img
6. Understanding the malware’s development timeline can offer insights into its deployment. What is the compilation UTC timestamp of the malware?
   • 2***-**-** **:**:**
   • We will use the same file we retrieved in question number 5, and use exiftool to pull the metadata of the suspicious file. Type exiftool file.0xca82b85325a0.0xca82b7e06c80.ImageSectionObject.***********.exe.img
   • The -05:00 on the timestamp means that I need to add 5 hours to get the UTC. If yours will show as +03:00, you will have to subtract 3 hours to get the correct timestamp. I hope that makes sense.
7. Identifying domains involved with this malware helps in blocking future malicious communications and identifying current possible communications with that domain in our network. Can you provide the domain related to the malware?
   • d*****.***
   • Use the hash value from our answer in question 5 and enter it into Virustotal. Go to the Relations tab and look into the Contacted Domains section, and you will find the answer.

Thank you for reading. I hope you enjoyed my post and that you find these entries helpful.

Please subscribe to my blog if you haven’t done so. Mahalo nui loa!!!!