Malware Analysis - Part 3: Basic Static Analysis Packer Limitation & .rsrc Malware Downloader

﷽ 

Hello and welcome to Part 3 of our malware analysis journey! 

Today, we'll revisit the basics of static analysis before advancing to the next stage. In the upcoming part, we'll dive into dynamic analysis to explore more advanced aspects of our study.

Packer Analysis Limitation

Here's the signature that we will examine:

https://www.virustotal.com/gui/file/7983a582939924c70e3da2da80fd3352ebc90de7b8c4c427d484ff4f050f0aec

The most common signature is that of a file packed with the FSG packer

Lets confirm again from the sample if there are other indications of protection that we can find more

We ran several tool to identify the packer and it identifies the packer as FSG 1.0 -> dulek/xt.

Several indications that the file is packed. The first is that the file sections have no names.

We see that the first section has a virtual size of 0x3000, but a raw data size of 0.

Not much import we can get here. To confirm that the file is packed, we searched for the imports, but there doesn’t seem to be an import table.

An executable file without an import table is extremely rare. If you encounter something like this, you can run several tools to check the confirmation.

By opening other tools, we see that it does have an import table, but it imports only two functions: LoadLibrary and GetProcAddress.

Packed files often import only these two functions, which further indicates that this file is packed.

In the future, we'll delve into the art of unpacking skills.

.rsrc Malware Downloader

https://www.virustotal.com/gui/file/0fa1498340fca6c562cfa389ad3e93395f44c72fd128d7ba08579a69aaf3b126/detection

As you can see from the details, the compiled time for this sample is Tuesday 05 July 2011, 19.16.15. 

Surprisingly, according to the file header, this program was compiled in August 2019. The compile time is faked, and we can’t determine when the file was compiled.   

Next, Let's observe if there are any indications of protection that we can find. 

Result: After we analyzed it statically there's no protection was applied in this sample. 

Here's what interesting things we found:

KERNEL32.dll Imports:

• WinExec - executes a file on the disk
• WriteFile - Writes data to a file
• CreateFileA - Creates a new file, opens an existing file, or creates a symbolic link
• SizeofResource - Determines the size of a resource in a module
• CreateRemoteThread - Creates a thread in a remote process
• FindResourceA - Finds a resource in a module
• GetModuleHandleA - Retrieves a handle to an already loaded module 
• GetWindowsDirectoryA - Retrieves the path to the Windows directory (We can also guess that the program writes files to the system directory because of the calls to GetWindowsDirectory)
• MoveFileA - Moves a file or directory, with the option to rename it
• GetTempPathA - Retrieves the path to the temporary directory
• GetCurrentProcess - Retrieves a handle to the current process
• OpenProcess - Opens an existing local process and obtains a handle to it
• LoadResource - Loads a resource from a module

ADVAPI32.dll Imports:

Program is doing something with permissions. we can assume that it tries to access protected files using special permissions.

• OpenProcessToken - Opens an access token for a process
• LookupPrivilegeValueA - Retrieves the locally defined value for a specific privilege
• AdjustTokenPrivileges - https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-adjusttokenprivileges

Next, we can observe also the strings inside the sample. 

urlmon.dll (External DLL download)

EnumProcesses

psapi.dll

sfc_os.dll

\system32\wupdmgrd.exe

\winup.exe

https://C2/X.exe

We know where it downloads the malware from, and we can guess where it stores the downloaded malware.

The only odd thing is that the program doesn’t appear to access any network functions.

Here's what we found more interesting within the .rsrc section. Let's analyze more into it

The resource section contains another PE executable.

The executable in the resource section is a downloader program that downloads additional malware.

We can therefore conclude that this resource is an additional executable file stored in the resource section.

We can save the binary file to analyze the file embedded within it.

https://www.virustotal.com/gui/file/819b2db1876d85846811799664d512b2f1af13e329f5debe60926c3b03424745/detection

Looking at the imports, we see that the embedded file is the one that accesses the network functions (urlmon.dll).

It calls URLDownloadToFile, a function commonly used by malicious downloaders.

It also calls WinExec, which probably executes the downloaded file. That concludes our basic static

analysis that this malware is a type of malicious code that downloads and/or drops additional malware onto a system.

Static analysis is typically only the first step, and further analysis is usually necessary.   

I hope this blog post proves beneficial, offering insights that can be valuable in raising awareness, 

and empowering cyber defenders to effectively analyze and combat malware.   

Thank you for your time, enjoy delving into the malware domain, and until we meet again for the next part, in which we'll dive into dynamic analysis to explore more advanced aspects of our study.

This is a practical case for educational purposes only.