Dynamic Analysis
Dynamic analysis involves launching and monitoring malicious software to analyze its behavior and runtime characteristics throughout its execution. It allows us to assess the impact of malicious software on the host system. Since we don't want to run malicious software directly to prevent any potential harm it may cause, we take specific steps to isolate and then analyze its execution.
On the other hand, static analysis doesn't analyze the code while it's running. Instead, it examines files for malicious intent. This proves useful in identifying infrastructure, packed files, and libraries. Some technical indicators can be used to determine if a file is malicious. However, detecting complex malware is challenging as it doesn't execute the code. If the malware author has used a custom packer, the analyst needs to understand this in static analysis and start the analysis after unpacking the package.
Dynamic analysis runs any suspicious malicious code in a secure environment called a sandbox (in our case, a virtual environment like Windows 10). Dynamic analysis allows security experts to observe malware while it runs, ensuring that it doesn't impact the system or take preventive measures. It provides deeper visibility to uncover the true nature of the threat. Cybercriminals often hide their code in a virtual environment that won't execute until certain conditions are met. It's important to note that performing dynamic analysis in a protected environment is crucial to prevent the actual infection of production systems by malicious software.
Measures
Before conducting dynamic analysis of malicious software, ensure that you do it in a secure environment. Consider deploying a Windows virtual machine and using VMware (or VirtualBox) to provide virtualization. Additionally, take a snapshot of the virtual machine before running malicious binary files to easily restore to a secure state.
Dynamic analysis can be categorized into two types:
Monitor Changes
Behavior Monitoring
Tools Used
Regshot
Fakenet
Procmon
Procdot
Before conducting dynamic analysis of malicious software, ensure that you do it in a secure environment. Consider deploying a Windows virtual machine and using VMware (or VirtualBox) to provide virtualization. Additionally, take a snapshot of the virtual machine before running malicious binary files to easily restore to a secure state.
Dynamic analysis can be categorized into two types:
Monitor Changes
Behavior Monitoring
Tools Used
Regshot
Fakenet
Procmon
Procdot
Regshot: The tool operates based on snapshots. It allows us to examine the differences between taken snapshots (first shot, second shot) and make comparisons. This tool is not only useful for analyzing malicious software but also for examining changes made in specific directories or on disks on your computer. For example, you can set the directory to be examined as the Desktop and change your desktop background, and this change will be reflected in the output between snapshots. Although it generally has the feature of monitoring the Registry (Regedit) during observation, both registry and directory observation capabilities exist in the process of malicious software analysis. The tool enhances usability by providing options for comparison and viewing the output based on the taken snapshots. (It presents the output in Notepad.)
Fakenet: The tool simulates legitimate network services, allowing you to block and redirect all or specific network traffic. Malware analysts can quickly determine the functionality of malware and capture network signatures using FakeNet. In other words, it can restrict internet access when the malicious software is about to run and display the requests to the user. Therefore, we can view the connections of the malicious software in real-time.
Some of the features it provides include:
Configurable and portable columns for any event property
Filters can be set for any data field, including fields not configured as columns
Process Tree tool shows the relationship of all processes referenced in a trace
Procdot: Procdot is a tool that processes Sysinternals Process Monitor (Procmon) log files and PCAP logs (Windump, Tcpdump) to create a graph using the GraphViz package. This graph visualizes and interactively analyzes relevant activities in a customizable manner.
Some features the tool offers include:
Smart tracking algorithms to focus only on relevant things
Detection and visualization of thread injection
Correlation of network activities and the processes causing them
Smart tracking algorithms to focus only on relevant things
Detection and visualization of thread injection
Correlation of network activities and the processes causing them
Dynamic Analysis Workflow and Preliminary Information
The Registry keys mentioned above are some locations within the Registry that could allow malicious software to survive after the operating system is restarted. Therefore, if the malware attempts to create new keys and place anything in these locations, it is an indicator of danger.
HKLM: HKEY_LOCAL_MACHINE
HKU: HKEY_USERS
HKCU: HKEY_CURRENT_USER
\SOFTWARE" is located under the HKEY_LOCAL_MACHINE hive.
NOTE: If you are using a 64-bit operating system and your running program is also 64-bit, DLL files come from Windows\System32. On the other hand, if you are using a 64-bit operating system with a 32-bit program, DLLs come from the Windows\SysWOW64 folder.
The next thing to be aware of is the DLL search order. When a program is running, it will need to use APIs that export DLL files.
Therefore, DLL files typically follow the path of Windows or Windows\System32. Sometimes, malware attempts to preload by placing its own DLL version that is exactly the same as the system DLL. It can do this by placing it in a directory within its own directory. This is the directory search order, where the directory on the left is searched before the one on the right, and the first one found is executed.
NOTE: If you are using a 64-bit operating system and your running program is also 64-bit, DLL files come from Windows\System32. On the other hand, if you are using a 64-bit operating system with a 32-bit program, DLLs come from the Windows\SysWOW64 folder.
The next thing to be aware of is the DLL search order. When a program is running, it will need to use APIs that export DLL files.
Therefore, DLL files typically follow the path of Windows or Windows\System32. Sometimes, malware attempts to preload by placing its own DLL version that is exactly the same as the system DLL. It can do this by placing it in a directory within its own directory. This is the directory search order, where the directory on the left is searched before the one on the right, and the first one found is executed.
Let's start our dynamic analysis
1-) First, open Procmon (Process Monitor):
As seen in the image above, first, we stop the operation of our tool and then clear it.
2-) Open our Fakenet tool.
Fakenet will intercept the network traffic generated by our malicious software.
3-) Start our Regshot tool.
We take a snapshot of the C:\ directory because we need to look at the most basic level (C
to compare and contrast registry keys or other files that may be created.
We want to view the entire root system.
We don't take the second snapshot immediately because we need to conduct examinations on Procmon and run the malicious software to observe its effects.
4-) Resume the examination we stopped with Procmon.
Processes are starting to be listed for examination.
5-) Start our malicious software.
As seen in the image below, our malware has deleted itself:
6-) If we continue our examination on Fakenet:
From the image above, it's making a GET request to wpad.localdomain host. The User-Agent for the GET request to the /wpad.dat directory is WinHttp-Autoproxy-Service/5.1. So, we can say that there's an Automatic Proxy set for the browser in Windows Http. Additionally, it's making the request on port 80, and from the Content-Type directory, we can deduce the urlencoded information.
Then, a POST request is made to the host mbaquyahcn.biz on port 80. The length is 80 bytes (Content-Length), and the request body is a=&b=&c=%68%65%66%63%69%6A%67%64%64%61%61%61%78%79%79%76%79%76%73%70%71%74%71%71.
We have a POST request in the form of a.
We decoded the URLENCODING POST request in this way, and the data we obtained is as shown in the image above.
7-) Now, let's examine our malware for a specific period (5 minutes should be sufficient, but it depends on our preference) to check for any different requests or created directories, registry keys, etc.
Now, let's compare two connections made at specific intervals and intercepted by Fakenet:
The request is made to the same server, the POST request is the same, the directory is the same, the HTTP protocol version (1.1) is the same, and the Content-Type/User-Agent is the same, as seen in the images above.
The only noticeable difference is the encoded operation. In the first image, it starts with c=%79, while in the second image, it starts with c=%6F.
When we look at the other attempted requests, no different request related to these operations is captured. We can say that our malware repeats the same request.
Fakenet intercepts the traffic and behaves like a server but does not forward the traffic to the desired server.
The hostname is clearly visible for us here.
Host: mbaquyahcn.biz
Now, let's stop Procmon again and take our second snapshot on Regshot. This way, we can view any changes made and check for anything created during this process.
Perfect, the second one is completed.
9-) After completing the two snapshots, we can compare them and get our output.
When the comparison is completed, it will automatically open in Notepad.
If we examine it in Notepad:
Firstly, if we go through the Values Added, meaning the added values, there has been a Registry operation as we mentioned before:
So, to ensure persistence (to run again after a reboot), a registry key has been created, and the file is named lsass.exe.
NOTE: In the image below, when we view the directory of the created exe file, the file is hidden.
File Not Found is saying, meaning there is no such file
Let's try to find our .exe file from File Explorer then.
We cannot view hidden items.
When we activate the "Hidden items" option from the View tab, several files like AppData become visible.
And as you can see, we are viewing our created malicious file.
*Now we know where the malware has stored a copy.
Now, let's look at the added files (Folders added).
This is the path where our malware has copied itself.
The file created to place lsass.exe inside.
1-) First, open Procmon (Process Monitor):
As seen in the image above, first, we stop the operation of our tool and then clear it.
2-) Open our Fakenet tool.
Fakenet will intercept the network traffic generated by our malicious software.
3-) Start our Regshot tool.
We take a snapshot of the C:\ directory because we need to look at the most basic level (C
to compare and contrast registry keys or other files that may be created.We want to view the entire root system.
We don't take the second snapshot immediately because we need to conduct examinations on Procmon and run the malicious software to observe its effects.
4-) Resume the examination we stopped with Procmon.
Processes are starting to be listed for examination.
5-) Start our malicious software.
As seen in the image below, our malware has deleted itself:
6-) If we continue our examination on Fakenet:
From the image above, it's making a GET request to wpad.localdomain host. The User-Agent for the GET request to the /wpad.dat directory is WinHttp-Autoproxy-Service/5.1. So, we can say that there's an Automatic Proxy set for the browser in Windows Http. Additionally, it's making the request on port 80, and from the Content-Type directory, we can deduce the urlencoded information.
Then, a POST request is made to the host mbaquyahcn.biz on port 80. The length is 80 bytes (Content-Length), and the request body is a=&b=&c=%68%65%66%63%69%6A%67%64%64%61%61%61%78%79%79%76%79%76%73%70%71%74%71%71.
We have a POST request in the form of a.
We decoded the URLENCODING POST request in this way, and the data we obtained is as shown in the image above.
7-) Now, let's examine our malware for a specific period (5 minutes should be sufficient, but it depends on our preference) to check for any different requests or created directories, registry keys, etc.
Now, let's compare two connections made at specific intervals and intercepted by Fakenet:
The request is made to the same server, the POST request is the same, the directory is the same, the HTTP protocol version (1.1) is the same, and the Content-Type/User-Agent is the same, as seen in the images above.
The only noticeable difference is the encoded operation. In the first image, it starts with c=%79, while in the second image, it starts with c=%6F.
When we look at the other attempted requests, no different request related to these operations is captured. We can say that our malware repeats the same request.
Fakenet intercepts the traffic and behaves like a server but does not forward the traffic to the desired server.
The hostname is clearly visible for us here.
Host: mbaquyahcn.biz
Now, let's stop Procmon again and take our second snapshot on Regshot. This way, we can view any changes made and check for anything created during this process.Perfect, the second one is completed.
9-) After completing the two snapshots, we can compare them and get our output.
When the comparison is completed, it will automatically open in Notepad.
If we examine it in Notepad:
Firstly, if we go through the Values Added, meaning the added values, there has been a Registry operation as we mentioned before:
So, to ensure persistence (to run again after a reboot), a registry key has been created, and the file is named lsass.exe.
NOTE: In the image below, when we view the directory of the created exe file, the file is hidden.
File Not Found is saying, meaning there is no such file
Let's try to find our .exe file from File Explorer then.
We cannot view hidden items.
When we activate the "Hidden items" option from the View tab, several files like AppData become visible.
And as you can see, we are viewing our created malicious file.
*Now we know where the malware has stored a copy.
Now, let's look at the added files (Folders added).
This is the path where our malware has copied itself.
The file created to place lsass.exe inside.
Let's move on to Procdot Analysis.
Let's perform a filtering process in Process Monitor.
In the above image, click on Architecture under Process Monitor Filter and then select Process Name from there.
From here, select Process Name as budget-report.exe, meaning we want to see our malicious software as a process.
After applying the filter, click on "Add" to add the filter, and your screen should appear with a green check mark as shown below.
Then, apply the filter.
Instead of 78,000 views, only our selected filter, which is our malicious software process, will be displayed (this reduces the displayed processes), which is budget-report.exe.
Let's continue with our filtering. If we were to create a list of filters:
In the Options tab, none of the features should be enabled, meaning none of them should be in an active state.
Go to Options > Select Columns > and enable Thread ID (TID).
Click on "Save" in the Files tab to save our Dynamic Analysis file.
NOTE: The reason for doing this is that it would be challenging to reinstall the operating system lab where the same malicious file was executed. Having the Process Monitor log from the executed environment in hand in a reviewable format makes our analysis easier.
Afterward, save it with the Comma-Separated Values (CSV) extension in the same directory. (Because we need to open it with a CSV extension in the Procdot tool.)
1-) Open our Procdot tool.
Click "Okay" to the dot.exe error that appears and proceed.
Click on the three dots next to the Procmon option and select our CSV file.
Then click on the three dots next to the Launcher and load it.
Choose our malicious software from the screen that appears.
When we select our malicious software with the PID (Process ID) number 5532 and click Refresh, we get:
This screen appears before us. We can zoom in and out of the indicated results with Ctrl + mouse wheel or drag and pull method to move right and left on the screen.
These are our Registry Keys for RunOnce to run again after a reboot (persistence) and the Registry Key for the privacy of the malicious file created inside the numerical file under the Roaming directory after the execution of the Hidden malware.
For example, our budget-report malware has been renamed as winlogon.exe under Roaming\12648430. Let's check from CMD to see if it's hidden or not.
Our directory is C:\Users\thres\AppData\Roaming\12648430, but it says "File Not Found" when using the dir command (dir: Shows the files in the current directory, similar to the ls command in Linux). Can we make it visible from our File Explorer and check?
Here, the reason for having sidebar.exe is that I needed to rerun my malicious file since I examined it in two headings, so it was renamed with a different name. However, the directory and file format of the created winlogon.exe are the same. So, by activating Hidden Items, we were able to view our malicious file (renamed malicious).
For example, this is from a different Regshot Comparison text file. Here, it has been renamed as lsass.exe again.
But upon re-examining the created Regshot Compare files (Regshot files created as logs),
we can confirm by comparing the 2nd and 1st snapshots in the Regshot Comparison that winlogon.exe has been created as a difference.
For example, if we were to examine in a different way:
Our malware has a thread with PID 8004.
Note: I will use the term "bağ" instead of "thread" here.
This thread
has created a file.
The created file is a temporary batch (bat) file.
For example, the batch file created here (pink arrow) in the upper right triggers a process with PID 1932 (green arrow), which, in turn, terminates (kills) the cmd.exe with PID 9132.
NOTE: Having knowledge of which directory and what each file (prefetch, batch, tmp) does can help us conduct our analysis more effectively by tracking them with arrows. Having knowledge of Windows specifics will make our job even easier.
Additionally, the process with the number 1932 in the above image is creating the Conhost.exe process, and it is connected to 3644.
Returning to our Persistence Registry Key, our renamed winlogon.exe sets itself as the value for that key.
NOTE: When used in conjunction with Procmon, the tool called Procdot provides us with crucial information, strengthening the foundation of our analysis. Using these two tools together, we can understand processes that are unclear in Process Monitor, figure out where they are headed, and make assumptions.
Let's perform a filtering process in Process Monitor.
In the above image, click on Architecture under Process Monitor Filter and then select Process Name from there.
From here, select Process Name as budget-report.exe, meaning we want to see our malicious software as a process.
After applying the filter, click on "Add" to add the filter, and your screen should appear with a green check mark as shown below.
Then, apply the filter.
Instead of 78,000 views, only our selected filter, which is our malicious software process, will be displayed (this reduces the displayed processes), which is budget-report.exe.
Let's continue with our filtering. If we were to create a list of filters:
In the Options tab, none of the features should be enabled, meaning none of them should be in an active state.
Go to Options > Select Columns > and enable Thread ID (TID).
Click on "Save" in the Files tab to save our Dynamic Analysis file.
NOTE: The reason for doing this is that it would be challenging to reinstall the operating system lab where the same malicious file was executed. Having the Process Monitor log from the executed environment in hand in a reviewable format makes our analysis easier.
Afterward, save it with the Comma-Separated Values (CSV) extension in the same directory. (Because we need to open it with a CSV extension in the Procdot tool.)
1-) Open our Procdot tool.
Click "Okay" to the dot.exe error that appears and proceed.
Click on the three dots next to the Procmon option and select our CSV file.
Then click on the three dots next to the Launcher and load it.
Choose our malicious software from the screen that appears.
When we select our malicious software with the PID (Process ID) number 5532 and click Refresh, we get:
This screen appears before us. We can zoom in and out of the indicated results with Ctrl + mouse wheel or drag and pull method to move right and left on the screen.
These are our Registry Keys for RunOnce to run again after a reboot (persistence) and the Registry Key for the privacy of the malicious file created inside the numerical file under the Roaming directory after the execution of the Hidden malware.
For example, our budget-report malware has been renamed as winlogon.exe under Roaming\12648430. Let's check from CMD to see if it's hidden or not.
Our directory is C:\Users\thres\AppData\Roaming\12648430, but it says "File Not Found" when using the dir command (dir: Shows the files in the current directory, similar to the ls command in Linux). Can we make it visible from our File Explorer and check?
Here, the reason for having sidebar.exe is that I needed to rerun my malicious file since I examined it in two headings, so it was renamed with a different name. However, the directory and file format of the created winlogon.exe are the same. So, by activating Hidden Items, we were able to view our malicious file (renamed malicious).
For example, this is from a different Regshot Comparison text file. Here, it has been renamed as lsass.exe again.
But upon re-examining the created Regshot Compare files (Regshot files created as logs),
we can confirm by comparing the 2nd and 1st snapshots in the Regshot Comparison that winlogon.exe has been created as a difference.
For example, if we were to examine in a different way:
Our malware has a thread with PID 8004.
Note: I will use the term "bağ" instead of "thread" here.
This thread
has created a file.
The created file is a temporary batch (bat) file.
For example, the batch file created here (pink arrow) in the upper right triggers a process with PID 1932 (green arrow), which, in turn, terminates (kills) the cmd.exe with PID 9132.
NOTE: Having knowledge of which directory and what each file (prefetch, batch, tmp) does can help us conduct our analysis more effectively by tracking them with arrows. Having knowledge of Windows specifics will make our job even easier.
Additionally, the process with the number 1932 in the above image is creating the Conhost.exe process, and it is connected to 3644.
Returning to our Persistence Registry Key, our renamed winlogon.exe sets itself as the value for that key.
NOTE: When used in conjunction with Procmon, the tool called Procdot provides us with crucial information, strengthening the foundation of our analysis. Using these two tools together, we can understand processes that are unclear in Process Monitor, figure out where they are headed, and make assumptions.
I'm glad if I could assist you with any topic, whether it's about malware, dynamic analysis, or Procdot analysis. I hope you found the information helpful, and I'm here to help with any more questions or information you might need. I hope you enjoyed the reading
BLUE TEAM
Source: @borekaenxd97 https://www.turkhackteam.org/konular/zararli-yazilim-dinamik-ve-procdot-analiz.2017260/
BLUE TEAM
Source: @borekaenxd97 https://www.turkhackteam.org/konular/zararli-yazilim-dinamik-ve-procdot-analiz.2017260/
Son düzenleme:
