BulkExtractor is a command-line tool that carve data such as URLs, emails, and PDF files.
Windows Memory contains rich and valuable information that can be used as source artifact for gathering evidences and by having enough knowledge how to parse the data can be helpful for the investigator to perform their tasked.
Volatility is a tool used for the extraction of digital artifacts from volatile memory (RAM) samples. Volatility uses a set of plugins that can be used to extract these artifacts in a time-efficient and quick manner.
UserAssist– a volatility plugin that is used to print userassist registry keys and information.
From an incident response perspective, the volatile data residing inside the system’s memory contains rich information such as passwords, credentials, network connections, malware intrusions, registry hives, and etc. that can be a valuable source of evidence and is not typically stored on the local hard disk. This is one of the investigator’s favorite data sources to perform digital forensics on, and knowing the right tool to dump memory is a must.
Related Blog Post:
https://www.eyehatemalwares.com/incident-response/blog-ir/phishing-ir-approach/
mactime creates an ASCII timeline of file all activity. This tool can be used to detect anomalous behavior and be able to reconstruct events, its output is a .txt format that contains reconstructed activity.
Why Timeline?
Reconstructing the events can play an important role during the investigation, because it allows the investigator to rebuild the activities happened before and after the event was first detected. It allows the investigator to have a bird’s eye view of the activities done by a certain malware or a threat actors and used this to construct a systematize action.
To be able to use this tool, first we must install Perl.
On Strawberry Perl’s website, download perl that suits your Windows Architecture.
Next, download Sleauthkit. (As of, Sleauthkit’s version is currently 4.11.1)
Next, extract Sleauthkit.zip to C:\ drive.
Then, browse to the C:\Sleauthkit\bin directory and then copy it.
Now, go to Environment Variables and add the copied directory to Path variable.
In this demo, we will use a sample body file to be processed by mactime using the -b parameter.
Then, we save the output in a .txt format named mac_timeline.txt
Command: mactime.pl -b body.txt > mac_timeline.txt
Volatility is a tool used for extraction of digital artifacts from volatile memory(RAM) samples. Volatility uses a set of plugins that can be used to extract these artifacts in a time efficient and quick manner.
timeliner – a volatility plugin that is used to create timeline for various artifacts found in the memory.
From an incident response perspective, the volatile data residing inside the system’s memory contains rich information such as passwords, credentials, network connections, malware intrusions, registry hives, and etc. that can be a valuable source of evidence and is not typically stored on the local hard disk. This is one of the investigator’s favorite data sources to perform digital forensics on, and knowing the right tool to dump memory is a must.
Scenario: You are tasked with investigating an endpoint that is flagged by the IDS/IPS contacting a suspicious external server.
Approach: Detecting Clipboard Function Hooking
This approach answers the question(s):
What is name of malicious process?
What technique does this malware use for stealth operation?
When was the process started?
What type of malware was detected? How so?
In what family and variant does this malware belong?
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.
To detect the presence of a spyware info-stealing malware in the memory we need to enumerate Windows station.
Windows Station contains information about clipboard activity and by analyzing this data source the analyst can detect clipboard snooping along with the frequency of clipboard usage which is a normal capability of a spyware.
To perform this task, we need to run Volatility wndscan plugin.
– –
First, open command prompt with administrator privilege and run the following syntax:
In Windows: vol.exe -f <mem.dmp> –profile=<OS> wndscan
In Linux: python vol.py -f <mem.dmp> –profile=<OS> wndscan
– –
We need to pay attention on the details inside spwndClipViewer which give us an overview on what process tries to own the clipboard function.
In this case, we see IEXPLORE.EXE:1560 in WinSta0 which a reg flag for us because why is the internet facing process such as internet explorer tries to access and monitor our clipboard.
– –
Through this data we can now then start our triage to support our investigation.
From performing this approach we are able to answer the question:
“What is name of malicious process?” A: IEXPLORE.EXE:1560
We are now proceeding to Step 2: Enumerating the Target Process.
Now, we have identified our target process from enumerating Windows Station.
We can now list the process using Volatility pslist and cmdline plugin.
To perform this task.
– –
First, run Volatility pslist plugin.
In Windows: vol.exe -f <mem.dmp> –profile=<OS> pslist -p 1560
In Linux: python vol.py -f <mem.dmp> –profile=<OS> pslist -p 1560
– –
Next, run Volatility cmdline plugin to know if this process resides on its original location.
In Windows: vol.exe -f <mem.dmp> –profile=<OS> cmdline -p 1560
In Linux: python vol.py -f <mem.dmp> –profile=<OS> cmdline -p 1560
In this case, we see internet explorer is a legitimate process.
– –
We have identified that the process is legitimate but it does not make sense because this process is monitoring our clipboard function.
From performing this approach, we can now answer the following question:
“When was the process started?” A: 2016-04-30 17:41:34 UTC+0000
Now, we are ready to dig deeper and proceed to Step 3: Identifying Process Injection.
We identified that our target process is a legitimate Internet Explorer process but this doesn’t seem right.
We have to dig deeper.
From a malware analysis perspective, we know that a malware can inject code from another process(legitimate process mostly) to perform its malicious intent and to avoid detection.
To hunt for this injection process,
– –
First, run Volatility malfind plugin.
In Windows: vol.exe -f <mem.dmp> –profile=<OS> malfind -p 1560
In Linux: python vol.py -f <mem.dmp> –profile=<OS> malfind -p 1560
In this case, we see that malfind detects discrepancies on 0x10000000 virtual address.
– –
What we see from this result are:
Red Flag #1: 0x10000000 has PAGE_EXECUTE_READWRITE Memory Protection
Red Flag #2: 5a4d MZ – Executable running from this memory region.
This can give us an idea that this memory region was injected with malicious code.
– –
Now, we identified the discrepancies and also see why our target process IEXPLORE.EXE:1560 is behaving oddly.
From this approach, we can now answer the question:
“What technique does this malware use for stealth operation?” A: Remote Process Injection
Now, we are ready to proceed on the next step. Step 4: Extraction of Suspicious Memory Region.
Now, we have identified the reason why our target process is monitoring Windows Station clipboard activity.
The next step we need to do is to extract this memory region that we suspectedly identified being injected with a malicious code.
To perform this task,
– –
First, we need to copy the identified injected memory region.
In Windows: vol.exe -f <mem.dmp> –profile=<OS> vaddump -p 1560 -b 0x10000000 -D <dir>
In Linux: python vol.py -f <mem.dmp> –profile=<OS> vaddump -p 1560 -b 0x10000000 -D <dir>
In this case, we successfully dump the suspicious memory region.
– –
Next, we extract strings from our extracted memory region.
The syntax will be like: strings.exe <memoryaddress_dmp> | findstr -i key
We pipe our result to findstr command to match “key” keyword.
– –
By performing the actions above, we were able to extract strings.
We can now see that this memory region has GetKeyboardState(), TServerKeylogger and etc. strings.
Now, we were able to identify that this memory region is injected with malicious keylogger malware.
– –
We can now able to answer the question:
“What type of malware was detected? How so?” A: Spyware or Info-stealing malware, it can monitor keyboard.
Now, we proceed to Step 5: Wrapping our Investigation.
Now, we are able to identify why our target process is behaving oddly.
We can now able to wrap our investigation, by hashing the extracted memory region and then submit to VirusTotal.
To perform this task,
– –
First, drag the dumped memory region to HashMyFiles tool and get the hash value.
Next, submit hash value to VirusTotal[.]com
Now, we are able to detect that our sample was then flagged by VirusTotal as malicious.
We can see that 40/67 AV Vendor detect it as malicious and some labeled it as Trojan.Fugrafa and RAT.XTREME malware.
– –
We can now answer the following question:
“In what family and variant does this malware belong?” A: XTREME RAT Family && Gen.Variant.Fugrafa.
Through this approach, we are able to detect a malware that can able to hook clipboard function and we were able to support our theory and then proved it.
We know how to combine different Volatility plugins to helps us with our investigation.
#note: There are other approach for detecting spyware and this is just an example.
Feel free to explore and identify what suits your need. Happy learning.
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?
What technique does this malware use for stealth operation?
How many entries of malicious .exe found on the disk?
What type of malware was detected? How so?
Is there any additional file created? When was the file created?
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 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:
– –
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.
Scenario: You are tasked with the investigation of a disgruntled employee that was accused of accessing and deleting a confidential file.
Approach: Carving Artifacts for Deleted File
This approach answers the question(s):
What is the accessed file’s name?
What is the file name after being deleted?
Was the file opened? How so?
When was the file created, accessed, modified and deleted?
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 this lab, we are going to mimic a scenario that someone opened and deleted a confidential file.
To begin, we will be creating a sample text file and name it “Credential.txt”.
We assume that the file was opened and deleted.
The image below is the creation of text file, then opening it, deleting it and finally clearing the recycle bin.
#note: When a disgruntled employee or an attacker accessed a file there is a possibility that they will delete it.
In order to proceed with the investigation, we will need to capture the volatile memory of the endpoint where the file was stored.
In our case, we will use AccessData FTK Imager.
To capture memory using this tool,
First, click the memory icon.
Next, choose the destination folder.
Optional, we can capture the “pagefile.sys” or create an “AD1 File”
Finally, hit “Capture Memory”
– –
Assuming we already have already acquired the volatile memory.
Now, we can extract the $MFT Entries found on that image.
– –
Steps:
First, we need to use a memory analysis tool.
In our case, we use Volatility with mftparser plugin.
Next, run the following syntax:
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, executing this command it will create a mft.txt inside the working directory and it extract all the $mft entries file inside mftentries directory.
Note: This syntax extract all the $mft entries found on the memory in a verbose mode. We can use also use the output body file using –output-file=body if the analyst prefer to have only a single file of the collected entries.
– –
After successfully extracting the $mft entries, we can then search for the file of interest using a search tool.
We can perform this task by runnin the following syntax: findstr -i “confidential” mftentries\*.dmp
In Windows: findstr -i “sometext” dir\*.dmp
In Linux: grep -i “sometext” dir
Now, we can see that the keyword we searched was found at $mft entry file.0x266cdc00.data0.dmp
– –
Now, we found the string of interest we can now proceed to Step 4: Digging Deep.
After performing string search to the extracted $mft entries, we can now proceed to dig deeper with our investigation.
Since the keyword we searched was found in one of the address inside mftentries directory.
We have 2 option to view the data of this entry:
– –
Option 1: We can use Volatility mftparser with -o (offset) option to dump the data in our terminal.
We can run the following syntax to dump the data:
In Windows: vol.exe -f <mem_dump> –profile=<OS> mftparser -o <offset_addr>
In Linux: python vol.py -f <mem_dump> –profile=<OS> mftparser -o <offset_addr>
#note: Copy the offset address from the result of findstr command.
– –
Option 2: We can use a string extracting tool like BinTexT to view the data inside.
We can do Option 2 by dragging the $mft entry to text extraction tool like BinTexT as seen from the previous step.
– –
After performing Option 1, we can now see the data inside the target $mft entry.
We can also see the file name after being deleted.
From here, we can then answer the question: “What is the file name after being deleted?” A: $R9DLA6G.txt
From here, we can then answer the question: “When was the file accessed, modified and deleted?” A:
From the previous step, we identified the file name after it was deleted and the date/time artifacts
Now, in this step we will answer the question:
“Was the file opened? How so?”
“What is the accessed file’s name?”
To do this task,
– –
First, we need to open the mft.txt which contains the verbose mode of $mft entries extraction.
Next, we will search for the file name itself.
In our case, we are interested with the string “Confidential” since it gives us a result when finding strings from the extracted $mft entries.
– –
After a few search, we land of this data: CONFID~1.LNK and Confidential.txt.lnk
From this data, we can see the file name Confidential.txt and .lnk file which is a shortcut file created when the file was opened.
Using the approach discussed above, we answered all of the questions needed for our investigation, including identifying the file name, the date/time of the file access and modification, locating the file name after it was deleted, and finally concluding that the file was accessed.
We can collect artifacts useful for our investigation by using memory forensics.
We are not claiming or assuming that memory forensics alone can provide us with this type of evidence because there are other methods for locating these artifacts on Windows systems.
This is just one approach; depending on your situation, you can use others such as Registry, Jump List, and so on.
PS:
Why we came up with the keyword “confidential” for string search or file search?
There are many ways for example, communicating with the file owner and use the information to start triage.
Remember: In performing forensics you have to start on what you know and what are the data at hand.
Scenario: Investigating the volatile memory of the suspected endpoint.
Approach: In memory strings extraction
This approach answers the question(s):
How does the malware persist on the system?
What is the URL used by the malware sample to beacon and contact its owner?
What is the network-based indicators of compromise for this sample?
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 this step, we will extract all the strings inside our captured volatile memory.
In this case, we are using Windows platform for analysis and we can use Sysinternals strings.exe to perform this task.
– –
First, copy strings.exe to directory.
Next, open command prompt and run as administrator.
Then, run the following syntax: strings -o <memory.dump> > <somestrings>.txt
Depending on the size of the memory dump, this will take some time.
– –
After extraction we can now then open the .txt file generated by strings.exe and we can see that the output strings are less valuable.
In this step, we will translate our newly captured raw strings to memory.
What it does is match the corresponding strings to its owner process and offset address.
– –
To perform this task, we will use Volatility strings plugin.
First, we need to download volatility.
Next, open command prompt with administrator privilege.
Then, run the following Volatility syntax:
In Windows: vol.exe -f <mem.dmp> –profile=<OS> strings -s <raw_strings>.txt > <somestrings>.txt
In Linux: python vol.py -f <mem.dmp> –profile=<OS> strings -s <raw_strings>.txt > <somestrings>.txt
– –
After we execute the command, volatility strings plugin mapped the strings to its owner process with address.
In the image below, (1)raw dumped strings using strings.exe and (2)translated strings.
We now have valuable strings that can help us with our investigation.
– –
We can now perform step 3: Extracting CNC artifacts.
In this step, we will use regex to find our strings of interests.
Regex search in the form of patterns, all that matches this pattern will be dumped.
– –
To perform this step, we will use Eric Zimmerman bstrings.exe tool.
First, download bstrings.exe from EZ tools.
Next, open cmd prompt or powershell with administrator privilege.
Then, run the following syntax to check regex search names: bstrings.exe -f <file>.txt -p
Finally, we will use ipv4 regex pattern to be fed to –lr option.
Our syntax will be like:
Syntax 1: bstrings.exe -f <file>.txt -p
Syntax 2: bstrings.exe -f <file>.txt –lr ipv4 > <dump>.txt
– –
After searching for ipv4 regex patterns, we can then use text editing tool to view our dumped strings.
Next, perform a quick search ctrl + F to find “http://” keyword.
Then, use the http://<some_ip> as a search keyword.
Now, we can see 5 hits from PID 1412, 2424, 596
– –
Now, we are ready for step 4: Hunting Suspicious Process.
In this step, we already know the process IDs who performed external beacon.
In our case, Process IDs 1412, 2424, 596 are the processes who performed the actions.
We will check these processes using Volatility pslist plugin.
– –
To perform this task,
First, open command prompt with administrator privilege.
Next, run the following syntax:
In Windows: vol.exe -f <memdump> –profile=<OS> pslist -p 1412,2424,596
In Linux: python vol.py -f <memdump> –profile=<OS> pslist -p 1412,2424,596
– –
After running the syntax, we can now map the following PIDs.
Process Name: winlogon.exe PID:596
Process Name: TPAutoConnect PID: 2424
Process Name: svchost.exe PID: 1412
– –
First, we list all svchost.exe to compare and find discrepancies.
We will use piping to filter process only on svchost.exe. To perform, run the following syntax:
In Windows: vol.exe -f <memdump> –profile=<OS> pslist | findstr -i “svchost”
In Linux: python vol.py -f <memdump> –profile=<OS> pslist | grep -i “svchost”
Now, we have listed all svchost.exe.
– –
We can now then view all svchost.exe. Can you spot the odd detail?
When listing all svchost.exe all processes have 448 as Parent Process ID.
Remember, we are looking for discrepancies.
Now, only svchost:1412 has different Parent Process ID means it spawned by other process which is odd.
– –
We now identified svchost.exe:1412 as suspected process.
We are now ready for Step 5: Digging Deep on Suspicious Process.
In this step, we already identified a suspicious process svchost.exe:1412
Quick note that legitimate svchost.exe resides at C:\Windows\System32 otherwise, not legitimate.
In this case, we need to know if svchost.exe:1412 is legitimate or not.
– –
To perform this task,
First, we will use Volatility dlllist plugin. We can run the following syntax.
In Windows: vol.exe -f <memdump> –profile=<OS> dlllist -p <PID>
In Linux: python vol.py -f <memdump> –profile=<OS> dlllist -p <PID>
Next, check if the process is residing inside the legitimate directory.
– –
In this case, svchost.exe:1412 is legitimate process because it is found in C:\Windows\System32
This should raise the question:
“How was this possible that a legitimate process contacting a malicious server?”
– –
In this state, we identified that the svchost.exe:1412 is a legitimate process but the details is not enough.
We already know that our suspected process is a legitimate process but it does not make sense since it is contacting a malicious server.
In this step, we will answer the question “How does that possible?”.
From a malware analysis perspective, a malware can bypass detection from security tools by performing remote process injection.
This way malware can use legitimate process to perform its malicious intent without being detected by AV or security product.
– –
We will use Volatility malfind plugin. What malfind does is, it looks for discrepancies inside the process memory.
To detect type of malware approach,
First, open command prompt with administrator privilege.
Next, run the following syntax:
In Windows: vol.exe -f <memdump> –profile=<OS> malfind -p <PID>
In Linux: python vol.py -f <memdump> –profile=<OS> malfind -p <PID>
– –
After running volatility malfind, it flagged 0x400000 offset address.
Why? Because, it finds 4d5a MZ signature inside the process memory and also the PAGE_EXECUTE_READWRITE Memory protection.
#note: When the memory is assigned with PAGE_EXECUTE_READWRITE(0x40) memory protection it can edit the content inside that process(like a super user privilege). By that, malware uses this trick to inject its malware inside other’s process’s memory that is why there is an executable 4d5a MZ inside 0x400000 memory address.
– –
We have now answered our question. We detected that svchost.exe:1412 is spawned to launch the malicious code found at the specific address.
In this step, we already identified that the process svchost.exe:1412 is injected with malicious code and can be found at 0x400000 memory address.
We can perform dumping for this specific memory address using Volatility vaddump plugin.
– –
To perform this task,
First, open command prompt with administrator privilege and run the following syntax:
In Windows: vol.exe -f <memdump> –profile=<OS> vaddump -p <PID> -b <memory_address> -D <dir>
In Linux: python vol.py -f <memdump> –profile=<OS> vaddump -p <PID> -b <memory_address> -D <dir>
– –
We are now ready for Step 8: Wrapping our Investigation.
In this step, we already identified the malicious process and how was the process malicious.
We can now perform further analysis on the dumped memory address 0x400000.
To perform this task,
– –
First, we collect the hash value of the memory address.
In our case, we use the tool HashMyFiles to get the hash value to be used later for submission.
– –
Then, we search the strings inside.
In our case, we use bstrings.exe with ipv4 regex pattern and found more CNC artifact aside from the detected IP address.
– –
Finally, we submit the hash value to online heuristic platform Virustotal[.]com.
In our case, VT flagged our submitted sample malicious.
38/71 AV Vendor flagged it as malicious and some named it Win32.Trojan.Einstein
We were able to extract the CNC artifacts from the endpoint and answer our questions using this method.
We discovered that malicious code was injected into a legitimate process in order to carry out such malicious intent.
We understand how to combine a set of Volatility plugins with readily available external tools to aid us in our investigation.
Volatility is a tool used for extraction of digital artifacts from volatile memory(RAM) samples. Volatility uses a set of plugins that can be used to extract these artifacts in a time efficient and quick manner.
strings – a volatility plugin that is used to translate the offset in physical memory to their virtual memory address. The plugin traverses the page tables of all processes in the active process list, including the system process, which has the kernel address space mappings. Based on this mappings, it determines which processes were able to access the specified strings.
From an incident response perspective, the volatile data residing inside the system’s memory contains rich information such as passwords, credentials, network connections, malware intrusions, registry hives, and etc. that can be a valuable source of evidence and is not typically stored on the local hard disk. This is one of the investigator’s favorite data sources to perform digital forensics on, and knowing the right tool to dump memory is a must.
Using the Volatility strings plugin, we can translate raw dumped strings to match its process that able to access the specified string. Not only, giving us the ability to know who owns the specific string, but we can also see the address where the strings is found inside the memory.
Using this plugin, it can be very useful to the investigator during investigation to look for IOC specially strings inside the captured volatile memory.
The syntax will be like:
vol.exe -f <memdump> –profile=<OS> strings -s <rawstrings>.txt > translated_mapped.txt
Volatility is a tool used for extraction of digital artifacts from volatile memory(RAM) samples. Volatility uses a set of plugins that can be used to extract these artifacts in a time efficient and quick manner.
auditpol – a volatility plugin that is used to verify what types
of events to expect.By default, the Security event log is turned off in Windows XP.
From an incident response perspective, the volatile data residing inside the system’s memory contains rich information such as passwords, credentials, network connections, malware intrusions, registry hives, and etc. that can be a valuable source of evidence and is not typically stored on the local hard disk. This is one of the investigator’s favorite data sources to perform digital forensics on, and knowing the right tool to dump memory is a must.
Using the Volatility auditpol plugin, we can see what are the logs to expect when extracting event logs on our captured memory.
Here are some things to note when using auditpol plugin:
The syntax will be like:
In Windows: vol.exe -f <memdump> –profile=<OS> auditpol
In Linux: python vol.py -f <memdump> –profile=<OS> auditpol
#Note: For the sake of demo, we use Windows XP distro that is why all logs were disabled by default.
⚠️ YOU ARE TRYING TO DOWNLOAD A FILE THAT CONTAINS MALICIOUS EXECUTABLE ⚠️
eyehatemalwares is “PAY WHAT YOU CAN” project.
The zip file associated with this lab is password protected.
For hands-on experience, click the “Donate” button and you will be redirected to eyehatemalwares Paypal donation homepage or scan the QR Code below.
Click the “Download” button again to download the lab zip file.
After successful donation, email us the zip file name and the Paypal transaction details for the password.
Thank you for helping us build this community!
We will make sure that your donation will be use to bring more value to the community.
Contact us: About
– EHM Team
