We covered dynamically analyzing malware using process explorer to discover DLLs, handles, resource consumption, network activity and to uncover common malware techniques such as process hollowing and process masquerading. This was part of TryHackMe Basic Dynamic Analysis
Process Explorer is another very useful tool from the Sysinternals Suite. It can be considered a more advanced form of the Windows Task Manager. Process Explorer is a very powerful tool that can help us identify process hollowing and masquerading techniques.
Setting the Stage: The Analysis Environment
To begin the analysis, the “samples” folder located on the virtual machine’s desktop. This folder contains four executables, all named “Lew.” We execute the first “Lew” application, initiating the dynamic analysis process.
Initial Observations with Process Explorer
Immediately after the “Lew.exe” sample is run, Process Explorer is launched. A key initial takeaway is understanding Process Explorer’s intuitive color-coding system for processes:
- Pink: System services.
- Blue: Processes running under the current user’s account.
- Green: Newly created processes (our “Lew.exe” initially appears this way).
- Red: Terminated processes.
Examining Process Properties
The core of the analysis lies in inspecting the properties of the suspicious “Lew.exe” process. This is done by right-clicking the process and navigating through various tabs:
- Image Tab: This tab is a goldmine of information. It reveals:
- The full path of the executable (
C:\Users\Administrator\Desktop\samples\Lew.exe
). - The command line arguments used (if any).
- The parent process (in this case,
explorer.exe
). - The user account under which it’s running.
- Crucially, note the absence of a digital signature for “Lew.exe”, a common red flag for malware.
- The full path of the executable (
- TCP/IP Tab: Essential for identifying network activity, this tab displays any local and remote IP addresses the process is communicating with, along with connection states. In the initial observation, “Lew.exe” showed no active TCP/IP connections.
- Performance Tab: Provides a quick overview of the process’s CPU and memory usage, which can sometimes indicate resource-intensive malicious operations.
- Threads Tab: Lists all individual threads running within the “Lew.exe” process, along with their Thread IDs (TIDs) and CPU consumption. This can help identify suspicious or hijacked threads.
- Handles Tab: This tab is critical for understanding what resources the process is interacting with. It shows open files, registry keys, mutexes, events, and other system objects that “Lew.exe” has accessed or created. The video demonstrates scrolling through this list to get an overview.
- Security Tab: Displays the security permissions and privileges associated with the “Lew.exe” process, indicating what actions it’s allowed to perform on the system.
Neutralizing the Threat
After observation, you can terminate the suspicious process by right-clicking on “Lew.exe” in Process Explorer and selecting “Kill Process”, the application is forcibly stopped. It briefly turns red in the Process Explorer list before disappearing.
Process Masquerading
Malware authors sometimes use process names similar to Windows processes or commonly used software to hide from an analyst’s prying eyes. The ‘Image’ tab, as shown in the above screenshot, helps an analyst defeat this technique. By clicking the ‘Verify’ button on this tab, an analyst can identify if the executable for the running process is signed by the relevant organization, which will be Microsoft in the case of Windows binaries. In this particular screenshot, we can see that the Verify option has already been clicked. Furthermore, we can see the text ‘(No signature was present in the subject) Microsoft Corporation’ at the top. This means that although the executable claims to be from Microsoft, it is not digitally signed by Microsoft and is masquerading as a Microsoft process. This can be an indication of a malicious process.
We must note here that this verification process only applies to the Image of the process stored on the disk. If a signed process has been hollowed and its code has been replaced with malicious code in the memory, we might still get a verified signature for that process. To identify hollowed processes, we have to look somewhere else.
Process Hollowing
Another technique used by malware to hide in plain sight is Process Hollowing. In this technique, the malware binary hollows an already running legitimate process by removing all its code from its memory and injecting malicious code in place of the legitimate code. This way, while an analyst sees a legitimate process, that process runs malicious code of the malware author. Process Explorer can help us identify this technique as well. When we select ‘Image’, Process Explorer shows us strings present in the disk image of the process. When ‘Memory’ is selected, Process Explorer extracts strings from the process’s memory. In normal circumstances, the strings in the Image of a process will be similar to those in the Memory as the same process is loaded in the memory. However, if a process has been hollowed, we will see a significant difference between the strings in the Image and the process’s memory. Hence showing us that the process loaded in the memory is vastly different from the process stored on the disk.
TryHackMe Dynamic Malware Analysis Room Answers
~Desktop\Samples\1.exe
using ProcMon. This sample makes a few network connections. What is the first URL on which a network connection is made?What network operation is performed on the above-mentioned URL?
What is the name with the complete full path of the first process created by this sample?
~Desktop\samples\1.exe
creates a file in the C:\
directory. What is the name with the full path of this file?What API is used to create this file?
In Question 1 of the previous task, we identified a URL to which a network connection was made. What API call was used to make this connection?
We noticed in the previous task that after some time, the sample’s activity slowed down such that there was not much being reported against the sample. Can you look at the API calls and see what API call might be responsible for it?
What is the name of the first Mutex created by the sample ~Desktop\samples\1.exe? If there are numbers in the name of the Mutex, replace them with X.
Is the file signed by a known organization? Answer with Y for Yes and N for No.
Is the process in the memory the same as the process on disk? Answer with Y for Yes and N for No.
~Desktop\Samples\3.exe
using Regshot. There is a registry value added that contains the path of the sample in the format HKU\S-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXX-XXX\. What is the path of that value after the format mentioned here?