[MATT Wk 2] Practical - Basic Dynamic Analysis
These labs are based off the Week 2 Basic Dynamic Analysis - Practical. The labs can be found here. Note that these are my personal solutions and may not be 100% accurate.
Lab 01
For this lab, the file lab03-01.exe is provided. Before we delve into the dynamic analysis, we should first perform basic static analysis to gather some information about the file.
Basic Static Analysis + Q1 - What DLLs does the malware import? Could the malware be packed?
If we were to look at the PEiD scan of the file, we see PEncrypt 3.1 Final -> Junkcode, instead of a compiler.
A quick Google search shows that it is a packer, and encrypted the original code. Unfortunately, I couldn’t find an unpacker, and we would have to manually unpack it using a debugger (like IDA), but it’s beyond the scope of this lab. The alternative would be to perform basic dynamic analysis on the file.
Now, let’s look at the DLLs that the malware imports. Looking at dependency walker, we see that it only imports one DLL, KERNEL32.dll. Additionally, it only imports ONE function from it, which is ExitProcess. This is a strong indicator that the malware is packed.
Q2 - What are some strings that may provide useful information for analysis?
To further confirm this, and also to gain more information, we could use strings.
Here are some strings that may provide useful information for analysis:
| String | Description |
|---|---|
| CONNECT %s:i HTTP/1.0 | Malware connects to a server |
| SOFTWARE\Classes\http\shell\open\command | This registry key is responsible for defining the default action associated with opening HTTP links. The malware could modify this key to hijack the default behaviour of opening web links E.g.: Redirecting user to malicious websites |
| Software\Microsoft\Active Setup\Installed Components | This registry key is responsible for the installation of software during the setup process. Malware could add itself to this key to ensure it gets installed during system startup / other specific events. |
| www.practicalmalwareanalysis.com | Malware probably connects to this website |
| admin | - |
| VideoDriver | |
| WinVMX32- | |
| vm32to64.exe | |
| SOFTWARE\Microsoft\Windows\CurrentVersion\Run | This registry key allows programs/scripts to be auto executed when a user logs into the system. This allows malware to achieve persistence, continuing its malicious activities without user interaction. |
| SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders | This registry key contains subkeys that specify the location of system folders (Desktop, Start Menu, etc). Malware might modify these subkeys to change the locations of the folders, hiding malicious files. |
For the ones that have a blank description, it’s hard to tell what they are used for, so we need the basic dynamic analysis to tell us!
Set up + Q3 - Does the malware create a Mutex when it is running?
Since we know some information about the malware, we can proceed to the dynamic analysis. Before we run the malware, we should set up some monitoring tools:
- Process Monitor - To monitor file system changes
- Process Explorer - To monitor processes
- ApateDNS - To redirect DNS queries to localhost (Note: In case you weren’t listening in class, you have to change your preferred DNS server addr to 127.0.0.1)
- Regshot (1st shot) - To monitor registry changes
- Netcat - To listen for connections (80/443)
Right off the bat, there were a bunch of stuff going on. I’ll go through them one by one.
On the netcat side, we see some data being transferred via port 443. Given that it’s HTTPS, we can’t see the data since it’s encrypted. Nonetheless, this tells us that the malware is supposed to communicate with a server.
We can see that the malware is trying to connect to www.ngeeann-malwareparalysis.com
If we were to look at Process Explorer and look at what processes the malware spawns (ctrl + L to see the lower pane):
We can see that the malware does indeed create a Mutex when it is running.
Malware utilises Mutexes to ensure that only one instance of the malware is running at any given time. This is to prevent multiple instances of the malware from running, which could lead to conflicts and unintended behaviour.
Q4 - Does the malware load any new DLLs when running?
If we were to look at Process Monitor and filter for Load Image events, we can see that the malware does load a bunch of DLLs.
Alternatively, we could look at Process Explorer and see the DLLs that the malware loads (Ctrl + D. To switch back to handles view: Ctrl + H).
Q5 - Does the malware create any file? If so, what is the filename & location of the file?
We could go to Process Monitor and filter for CreateFile operation events.
Here, we can see that the malware creates several DLLs in the C:\Windows\System32 directory.
Malware often creates dlls in the System32 directory for persistence, stealth, or DLL hijacking (placing malicious dll with the same name to load it into legitimate processes instead of the “real” dll).
Q6 - What registry keys are being modified?
To find out what registry keys are being modified, we could filter for RegSetValue in Process Monitor.
There are two keys that are being modified:
HKLM\SOFTWARE\Microsoft\Cryptography\RNG\Seed and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VideoDriver
Malware modifies the cryptographic seed to ensure that the random numbers generated are predictable. This could be used to generate encryption keys, which could be used to encrypt/decrypt data.
Malware modifies the
VideoDriverkey to ensure that it is executed when the system starts up (It is part of theRunkeys, which allow programs to run automatically on startup).
Alternatively, we could take our second Regshot and compare it with the first one to see what registry keys have been modified.
It seems like there are more values detected by Regshot :O
Q7 - What DNS request is being made?
We saw earlier that the malware was trying to connect to www.ngeeann-malwareparalysis.com. After running the malware for around 30+ minutes, we can see that the malware has been requesting www.ngeeann-malwareparalysis.com every 1m1s past a certain point.
Q8 - Use netcat to listen to port 443. What data is being transferred?
We also saw this earlier, and I didn’t rerun the netcat instance. We can’t decipher the data since it’s encrypted anyway.
Conclusion
Side note: The PID is different here coz I restarted the lab,, I forgot to take this screenshot the first time round
The malware installs the vmx32to64.exe file, in the C:\Windows\System32 directory. With the registry keys modified, the malware vmx32to64.exe will be executed on startup, and possibly connect to the server www.ngeeann-malwareparalysis.com for other malicious payloads. To gain further information on what the malware does, we need to analyse the vmx32to64.exe file, which is beyond the scope of this lab.
Lab 02
For this lab, we will be using Lab03-02.dll. As usual, we should first perform basic static analysis to gather some information about the file.
Basic Static Analysis + Q1 - What are the imported & exported functions of this DLL?
Looking at Dependency Walker, we can see that the DLL imports a few dlls — KERNEL32.dll, ADWAPI32.dll, WS2_32.dll, WININET.dll and MSVCRT.dll.
We can also see that the DLL exports 5 functions. The most interesting ones would be Install and InstallA, which are probably going to be our entry points.
Looking more into some interesting imported functions:-
KERNEL32.dll
CreateProcessA- Creates a new process and its primary thread.GetCurrentDirectoryA- Retrieves the current directory for the current process. This could be used to determine the current working directory of the malware.GetLastError- Retrieves the calling thread’s last-error code value. Interesting?GetModuleFileNameA- Retrieves the full path and filename of the executable file of the current process. This could be used to determine the location of the malware.- …
ReadFile- Reads data from a file, starting at the position indicated by the file pointer.Sleep- Suspends the execution of the current thread for a specified interval. This could be used to delay the execution of the malware - a common evasion technique for sandbox environments!
ADWAPI32.dll
RegCloseKey/RegCreateKeyA/RegOpenKeyExA/RegQueryValueExA/RegSetValueExA- Functions related to registry manipulation.
WS2_32.dll
WSASocketA- Creates a socket! This could be used to establish a connection to a remote server.
WININET.dll
HttpOpenRequestA/HttpQueryInfoA/HttpSendRequestA- Functions related to HTTP requests. This could be used to communicate with a remote server.InternetConnectA/InternetOpenA- Functions related to internet connections, probably used to establish a connection to a remote server.InternetReadFile- Reads data from the specified file/URL/directory.
To get a better idea of what the malware does / what we should pay attention to, we could use strings.
We can see that the malware is probably trying to connect to ngeeann-malwareparalysis.com. We should also look out for svchost.exe processes, as well as registry keys being modified. Additionally, the malware seems to be using IPRIP for some sort of communication with the/a server.
Q2 - How do you install the malware? How do you run it after installing it?
Since the malware is a DLL, we can’t run it directly. Instead, we have to use the rundll32 command to run the DLL.
Before running the DLL, set up the necessary monitoring tools (same as Lab 01).
The way to install the malware is to run the following commands:
1
2
rundll32.exe Lab03-02.dll,Install
net start iprip
The command line would look something like this:
Q3 - What important functions are imported in the DLL?
Hey, we already did this in the basic static analysis :)
Q4 - Using Process Explorer, find the process under which the malware is running.
Initially, I thought the malware would show up as a separate process on its own, like it did in lab 03-01. Unfortunately, that didn’t show up. However, ApateDNS and netcat did show some activity, so I knew the malware was definitely running.
Earlier on, we saw that the strings of the malware had svchost.exe in it. Looking at Process Explorer, I saw that there were multiple instances of svchost.exe running. I hovered over each of them to see the command line arguments, and saw an interesting one.
The command line argument is quite similar to what we saw in the malware, and there’s suspiciously many services running under this svchost.exe process. This is probably the process under which the malware is running.
I also found out you could just search for the DLL name in Process Explorer, and it would show you the process that is running the DLL.
Q5 - Set a filter in Process Monitor to monitor the operations of the process identified in Q4.
Since we know the process that the malware is running under, we can set a filter for the PID (1196).
Q6 - What are some host-based indicators?
I got distracted halfway through this lab and left the malware running, so I had way too many logs, and I couldn’t filter them without having ProcMon complaining.
Anyway, I took a Regshot before running the malware. So, I could just take the 2nd shot and compare. There were a few things that caught my eye.
The malware added the IPRIP service, as expected. It also seems to be adding the dll into the IPRIP parameters, possibly for persistence.
Other than the service, the malware also modified the cryptographic seed, as like in the previous lab.
Q7 - What network-based indicators?
Domain: www.ngeeann-malwareparalysis.com
Port: 80
What is the data being transferred? Which protocol?: HTTP/1.1
It performs a GET request to /serve.html
Lab 03
For this lab, we will be using the Lab03-03.exe file.
Q1 - What are the imported DLLs of this malware?
Using Dependency Walker, we can see that the malware only imports KERNEL32.dll. While this is an indicator that the malware is packed, we find that we can see many imported functions from KERNEL32.dll. So, it doesn’t really seem that the malware is packed.
Q2 - Is the malware packed?
As mentioned earlier, the malware might not be packed, as we can see many imported functions from KERNEL32.dll.
To double-check, we could use PEiD to scan the file.
We can see the compiler is Microsoft Visual C++ 6.0, which is a good indicator that the malware is not packed.
So no, the malware is not packed.
Q3 - What happened when you execute the malware? What does the malware do before it exits?
Before running the malware, set up the necessary monitoring tools (same as the previous labs). Though there isn’t any network-based indicators, I’ll still run ApateDNS and netcat just in case.
When the malware is run, it starts a new process, svchost.exe, then exits.
The way that the svchost.exe process is run is quite interesting.
It is run as a parent process, instead of being run as a child process under System. Thus, we should grab the PID of this process and check it out in Process Monitor later on.
Q4 - Using Process Explorer, examine the Strings in the malware, on disk and in memory.
On disk, this malware doesn’t have any red flags. It seems to be the real svchost.exe file.
We can further confirm that it is the real svchost.exe file by verifying the digital signature.
HOWEVER, the verification only checks the file on DISK. This means that if the file was tampered with in memory, the verification would not detect it.
In memory, we can see that the malware has some interesting strings, which seems like a set of rules for a keylogger.
Q5 - Does the malware create any file?
We could go to Process Monitor and filter for the PID and CreateFile operation events.
We can see here that the malware tampers around with the creation of some dlls, and also creates a file where the malware was run from called practicalmalwareanalysis.log.
If we were to look at the contents of the log file, we can see that it logs the keystrokes and the titles of the windows that the user is interacting with.
Q6 - What do you think is the purpose of the malware?
A keylogger :D
Conclusion
That’s it for this week’s labs :) Hope y’all learnt something!! <3 Peace out, A very tired Kairos