Memory Analysis Practice

As a DFIR enthusiast, my first post on this blog will be about memory forensics. The following mock case that I have been investigating is provided from DFIR madness by James Smith. The setting of this case involves a popular cartoon character's sauce recipe being leaked and as digital forensic examiners, we must attempt to uncover how this happened. Jumping forward to the analysis phase of the investigation, I will be examining the memory of the domain controller (DC) server. The conclusion of my findings are at the bottom of this post.

Lessons and experience taken from this challenge

• Understanding the advantages and goals of memory analysis
• Exposure to some memory forensics tools
• Examine the network connections of processes
• Recognize malicious processes
• Extract plaintext malware samples from memory
• Develop a list of IOCs to scope an investigations

Starting with the memory of the DC is a sound decision, because information was accessed from this server. One suspicion one may have is that malware was deployed to reach this recipe. A tactic that accomplishes this is allowing the malware to reside in memory which allows itself to be hidden.

A jumping off point for this server is understanding what kind of operating system one has. These details can be done by using Volatility. I later got a list of profiles of  potential versions of windows servers and cross referenced this with a photo taken from the incident responder. Confirming this as Microsoft Windows Server 2012 R2 Standard Enterprise.

Output from Volatility 2

Photo from an incident responder

Typically malware would need to establish a network connection with the attacker and in this case we know that the recipe was outed on the dark web. With that in mind, one would take a look on the processes that were running at the time of memory acquisition. These are the red flags I was looking out for.

• IP Addresses that may be flagged by other security institutes.
• Processes that don’t normally connect to the internet.
• Processes that don't normally exist natively to the windows operating system.
• Unusual amount of network traffic.

Suspicious Processes within DC Server

The results from the netscan yields a lot of activity from dns.exe, I will take a note of this just in case. Grep allows me to see the other processes of which one can reasonably review. While checking these processes with Google I found a suspicious process labeled “coreupdater.ex” (suspected typo from the author). Search results outline potential malware, and nothing that indicates this as native to the Windows OS. This process was communicating with an IP address that at the time of the breach resolved to "happydoghappycat-th[.]com". Using a domain lookup search engine such as Talos Intelligence, Whois info reveals this site was created one month ago. Too new for someone in this household to want to connect, especially within Thailand.

Offset(P):0x20fc7590

Protocol:TCPv4

Local Address:10.42.85.10:62613

Foreign Address:203.78.103.109:443

State: ESTABLISHED

Pid:3644

Owner: coreupdater.ex

Created: Nothing

coreupdater.ex process information from netscan

Google search results of coreupdater.exe

DNS results

Whois info from Talos Intelligence

Malfind

Malfind is a tool used by examiners that does good work in narrowing in on process IDs that are suspicious. This tool examines for any signs of injected code/DLLs in user-mode memory, based on characteristics such as VAD tags and page permissions. VAD, Virtual Address Descriptors, provides useful information about the address space of a specified process. They provide details about the PTE Protection Bits, inheritance of the page and wherever the page is being shared between processes.

With that said, we are provided some processes that we may examine more closely. Here I keep an eye out for any red flags within the assembly code. Primarily for assembly statements that follow a A-B-A pattern. This is a sign of code that was injected in this process. Malfind directs our attention to “spoolsv.exe”, which in fact holds this pattern as well as a XOR statement. This statement is known to cipher input.

One section of the spoolsv.exe that appears suspicious

We find another example of this pattern, however within the hex section a MZ statement is found. An indication that this as a portable executable file.

Second section of the spoolsv.exe that appears suspicious

Carving Processes with Malfind

Malfind has the ability to carve out processes from memory. This will allow me to examine the files with other AV tools. ClamAV reports 4 infected processes involving two types of malware, Meterpreter and Razy. After some searching, one can understand that Meterpreter is a payload typically assembled under Metasploit. It attempts to reside within memory through DLL injection. This malware will communicate with the network providing an interactive shell. These operations occur within native processes, it avoids to create new ones. Razy happens to be ransomware.

Fortunately, this tool lists out the memory address of where the detections took place. If we cross reference this with our previous findings, all four results lay within “spoolsv.exe”.

ClamAV scan on Maldump results

Further Analysis of Infected Processes

Here I copied these infected processes into its own directory and examine them through FLOSS. FLOSS is a tool that attempts to deobfuscate strings within Windows Portable Executable files. Successful deobfuscation may reveal other IOCs such as malicious domains and file paths.

We do find the same IP address associated with coreupdater.ex. Further validating the thesis that this process involves communicating with the attacker.

IP address found by FLOSS

Now one must assess the associations of spoolsv.exe and coreupdater.exe with the pstree flag.

pstree results

Some details to take note involve the parental relationship between the processes that we confirmed malicious. While spoolsv.exe relationship with services.exe doesn’t raise any red flags at the moment, process 2244 for coreupdater is gone. Additionally this process seems to have no active threads at this time.

Here we will use "pstree -v" to allow us to see the file path to these two processes, of which lead back to the system32 directory.

Filepath that lead to spoolsv and coreupdater

These file paths could help for when an examiner investigates any other red flags within the disk. This should be listed as a IOC from incident response purposes. Additionally it must be said that any change done in this directory requires admin privileges. Implying that our attacker has someone gotten themselves this type of access.

Conclusion

At this point, one has enough IOC to serve as pivot points when examining PCAP files or the Desktop Disk Image. I will end this post from here as it covers the examination made on this artifact. Before that however, here is a recap of everything that was covered.

1. Confirmed the type of operating system of the server.
2. Performed a netscan of processes.
3. Reviewed these processes that reveal one of which is unfamiliar by windows.
4. Examined the associated IP address of which resolves somewhere in Thailand.
5. Used Malfind to reveal that spoolsv.exe has characteristics common to injected code.
6. Used Malfind to carve and dump all processes of which are scanned by a AV program.
7. AV program informs us of malware within these processes, so FLOSS is performed to deobfuscate them.
8. The same IP address is found, further validating a connection between these two processes.
9. Used pstree to find out that system32 was likely accessed and the filepaths involve are now known to us as IOCs.

Here I suspect that meterpreter was used to pivot the attacker's operations from coreupdater to spoolsv. This pattern may be used to scope out an investigation within the file system of the desktop disk image.