Dumping .EXE Files using Memory Forensics

Read Lab Instruction

Scenario: You are tasked with investigating an endpoint that is flagged by the IDS/IPS contacting a suspicious external server.

Approach: Carving Executable Files Artifacts

This approach answers the question(s):

What is name of malicious process?

      • scvhost.exe:1676
      • wuaumqr.exe:1700

What technique does this malware use for stealth operation?

      • Pyscholinguistic technique

How many entries of malicious .exe found on the disk?

      • 2, 0x00000000001933740:wuaumqr.exe && 0x00000000001962f60:wuaumqr.exe

What type of malware was detected? How so?

      • Spyware or Info-stealing malware, it can monitor key strokes.

Is there any additional file created? When was the file created?

      • Yes, a log file keylog.txt 
      • Creation: 2014-10-22 17-09-32 UTC+0000

        Modified: 2014-10-22 17-09-32 UTC+0000

        MFT Altered: 2014-10-22 17-09-32 UTC+0000

        Access Date: 2014-10-22 17-09-32 UTC+0000

Below are the detailed step-by-step analysis taken to extract valuable information from the given memory sample.

#note: Use a separate isolated machine to perform this task.

In conducting digital forensic, we have to start with what we know.

Since we are tasked with investigating an endpoint that reports to a known malicious external server, we know that there might be a process responsible for this action.

To perform this task, we need to enumerate all the running processes inside our captured volatile memory.

– –

First, we will use Volatility pstree plugin to enumerate the parent-child relationship of all running processes.

To perform this task, we run the syntax:

In Windows: vol.exe -f <mem.dmp> –profile=<OS> pstree

In Linux: python vol.py -f <mem.dmp> –profile=<OS> pstree

In this case, we see red flag.

Red Flag 1: Process ID 1676,1700 with incorrect name scvhost.exe and wuaumqr.exe

– –

Next, we try to run Volatility pslist plugin with svchost.exe to see if there is PID: 1676.

To perform this task, we run the syntax:

In Windows: vol.exe -f <mem.dmp> –profile=<OS> pslist | findstr -i “svchost”

In Linux: python vol.py -f <mem.dmp> –profile=<OS> pslist | grep -i “svchost”

In this case, we see another red flag.

Red Flag 2: Enumerating svchost.exe no 1676 since it is spelled s”C”vhost.exe instead of s”V”chost.exe

#tip: This technique is called Pyscholinguistic technique. Malware authors used this for stealth technique and to avoid detection where they replace either a letter of a legitimate process or swapping it.

– –

Then, we try to run Volatility cmdline plugin with both PIDs 1676 and 1700 to view where was this executable located inside the disk.

To perform this task, we run the syntax:

In Windows: vol.exe -f <mem.dmp> –profile=<OS> cmdline -p <PID>

In Linux: python vol.py -f <mem.dmp> –profile=<OS> cmdline -p <PID>

In this case, we see wuaumqr.exe:1700 is residing at C:\Windows\System32

– –

After running these series of plugins and commands we can see the red flags of the processes.

Now, we can start on our investigation with this information.

Done by our analysis, we can now answer the questions:

What is name of malicious processes?scvhost.exe:1676 && wuaumqr.exe:1700

What technique does this malware use for stealth operation?” A: Psycholinguistic Technique

We are now ready for Step 2: Carving .EXE files.
 

We already identified the red flags just by running simple pslist and pstree plugin.

Now, we know that there are 2 processes involve name scvhost.exe:1676 and wuaumqr.exe:1700, we can search this executable from the memory using Volatility filescan plugin.

To perform this task,

– –

First, we need to extract all the file entries found in our memory:

In Windows: vol.exe -f <mem.dmp> –profile=<OS> filescan > filelist.txt

In Linux: python vol.py -f <mem.dmp> –profile=<OS> filescan > filelist.txt

– –

Next, we need to perform filtering to our extracted file entries using sysinternals strings.exe.

In Windows: strings -a <extracted>.txt | findstr -i “.exe” > exefiles.txt

In Linux: strings -a <extracted>.txt | grep -i “.exe” > exefiles.txt

Now, we successfully extracted .exe files.

– –

Having this artifacts, we can now proceed to Stage 3: Looking for .EXE files of Interest.

 

Now, having the artifacts we can now search for our file of interest.

From the previous analysis, we identified that there are processes involve with .exe file extension.

Now, we will use this information to start and know what we are looking for.

In our case, we are interested with the .exe file that resides inside C:\Windows\System32 which named wuaumqr.exe that we know mimic wuaumgr.exe(Windows Automatic Update Manager).

– –

First, open “exefiles.txt” with a text editor tool.

Next, search for “wuaumqr.exe”.

In this case, we can now see the suspicious .exe file and its equivalent Physical address.

We found 2 entries:

      • 0x00000000001933740:wuaumqr.exe
      • 0x00000000001962f60:wuaumqr.exe

– –

After performing such actions, we can confirm that our .exe file of interest resides on the disk and we identified that there are 2 entries.

Now, we will use the physical offset address of the found entries to extract these executable.

We run the following syntax:

In Windows: vol.exe -f <mem.dmp> –profile=<OS> dumpfiles -Q <physical_offset> -D <dir>

In Linux: python vol.py -f -f <mem.dmp> –profile=<OS> dumpfiles -Q <physical_offset> -D <dir>

In this case, we have extracted 2 artifacts of wuaumqr.exe

– –

Now, we have extracted the artifacts and can answer the question:

How many entries of malicious .exe found on the disk?

We are now ready to Step 4: Wrapping our Investigation.

 

Now, we have extracted artifacts related to our suspicious process. What to do now?

We can run strings and extract the data inside of these dumped executable.

– –

First, we extract all strings from our sample.

In our case, we can see words like “Keylogger” which gives us an indication that this executable is malicious.

We also, see strings like F5, F6 and other .exe which can be use to create our host-based IOC.

– –

Next, we hash our sample and submitted to VirusTotal[.]com.

In this case, VT results 47/54 AV Vendor flagged it malicious SpyBot:Keylogger.

 

 

 

Now, we identified that our sample is malicious and labeled as SpyBot Keylogger.

From a malware analysis perspective, Keylogger malware logs all the data, keystrokes to the disk before beaconing it towards the external server to be analyzed by its owner.

We will try to hunt this if there are any.

To perform this task:

– –

First, perform osint and check for additional information on VirusTotal[.]com

In this case, we see that this malware creates a text file named “keylog.txt” that is logged inside C:\Windows\System32

– –

Next, we extract $mft entries to see if we can find this log file.

In Windows: vol.exe -f <mem_dump> –profile=<OS> mftparser –output-file=mft.txt -D <dir>

In Linux: python vol.py -f <mem_dump> –profile=<OS> mftparser –output-file=mft.txt -D <dir>

After successful execution, we have extracted all $mft entries and dumped it to disk and save it in a text file.

– –

Now, we can perform simple search of this “keylog.txt” from the extracted $mft entries.

In this case, we can confirm that that “keylog.txt” was then found.

We can also see the date/time information:

      • Creation: 2014-10-22 17-09-32 UTC+0000

        Modified: 2014-10-22 17-09-32 UTC+0000

        MFT Altered: 2014-10-22 17-09-32 UTC+0000

        Access Date: 2014-10-22 17-09-32 UTC+0000

– –

Not only we found the additional file created, we also gather the date-time information which can really help if we timeline the incident.

Now, we can answer the question: “Is there any additional file created? When was the file created?”.

 

 

We were able to answer questions such as what process is responsible for communication, what is the stealth technique, where to find it on the disk, the sample type, the additional created file, and when the attack occurred using this approach.

All running executables, particularly processes, exist on the disk, and by performing file enumeration using memory forensics, we can obtain a large number of disk-related artifacts to aid our investigation.