"Cracking Open the Malware Piñata" Series: Intro to Static Analysis with Kazy Trojan
Updated: Jan 16, 2022
Static analysis, put concisely, is getting information from a specimen without actually executing/detonating it. While it is less "risky" in that the malware isn't actually running, it's also less informative than dynamic or code analysis. Regardless, static analysis can offer enough insight to characterize what the executable is doing and offer good leads into what the general behavior of the specimen is.
In this entry of the malware analysis series, I do a high-level walkthrough of static analysis techniques on a known malware specimen. Note that the order I conduct static analysis in isn't a requirement; different analysts have different preferences as far as their methods go.
Links to all tools will be at the bottom of the article. If you need help setting up a malware analysis environment, check out my previous blog post here.
PESTUDIO
One of the first tools I use when starting this stage of triage is PeStudio. Developed by Marc Ochsenmeier, it provides a phenomenal "first look" when interacting with a suspected malware sample. The user interface is very simple and allows you to drag-and-drop the specimen into the GUI.
As pictured, PeStudio immediately starts analyzing the file and offers useful information one can pivot on, such as hashes and file type. In the left pane, there are plenty of additional analysis views one can select. Notice that the VirusTotal option has an error: this is because the VM is configured to a host-only network adapter configuration and PeStudio was unable to reach out to VirusTotal as a result.
Moving into the indicators view, the tool lists 41 indicators that make the file suspicious, and ranks the indicators by severity on the right side of the GUI.
Under the "details" column in the indicators view, there are several references to UPX. UPX is an open-source executable packer, which compresses files and can mask their contents. Packers can have benign uses, such as protecting intellectual property, but malware authors can leverage them as an attempt to obfuscate their binaries.
My next stop in PeStudio is usually the sections view. Normal, unpacked executables usually have section headers named .text, .data, .rdata, .rsrc, amongst others, such as pictured below.
For our suspicious sample, the sections look like this:
Sections titled "UPX0" and "UPX1" further confirm the initial findings from the indicators view, pointing to a packed executable.
Next stop: imports. This section offers a lot of insight to the API modules imported by the specimen. When it comes to packed executables, visibility is extremely limited in this category and the entire list of imports isn't shown - yet. Despite this, the short list on the screen adds to our clues of what the malware is doing.
Even being packed, we can tell there's some level of registry and DLL interaction. For further details regarding these modules, Microsoft does a phenomenal job documenting the modules within its APIs.
My final usual stop in using this tool is the strings view. From here, analysts can again see some of the imports spotted in the previous view, but there are additional useful indicators at times. For example, if a malware author has hardcoded a domain or IP, it may be visible here. As is unfortunately the case, packed executables while packed don't offer too much, so here's what our specimen shows in PeStudio:
UNPACKING WITH UPX
Based on the findings in PeStudio, our analysis draws us to the likely conclusion that the executable is packed with UPX. We can confirm this by using a tool like ExeInfo PE, developed by A.S.L. The user interface is similar to PeStudio, where we can analyze the file by just dragging and dropping it on the GUI.
ExeInfo confirms that the file is indeed packed with UPX. UPX has the ability to unpack executables that it has packed, and it's incredibly easy to do so if it's been packed using default settings. This can be accomplished by opening a command window, moving into the directory where UPX is found, and running the command as pictured below:
The unpacked version of the executable has now replaced the packed instance, which we can confirm by again dragging and dropping into ExeInfo.
UNPACKED EXECUTABLE IN PESTUDIO
Now that a layer of obfuscation has been peeled off, we can go back to PeStudio and analyze the unpacked specimen with the hope of getting more indicators.
Right away, we can see that things look very different in PeStudio compared to when we assessed the packed version of the specimen, with many more indicators, imports, and strings:
If we move into the sections view, they're no longer UPX0 and UPX1, but look more like the sections I described previously
Looking at the imports view, we see many more and can get an even better idea of what this specimen is up to:
In addition to the registry and process interactions we saw before, we now see that the executable can read, create, and write to files. Of note, "GetTickCount" is one of the imported modules and could be of value to indicate that the malware may have anti-debugging capabilities. Microsoft's documentation mentions that this module "retrieves the number of milliseconds that have elapsed since the system was started." Malware developers can leverage this to see how long the process has been running, and if the time exceeds a threshold, the malware will terminate to prevent being analyzed in a debugger.
Finally, taking a quick look at the strings gives us even more insight:
On the right side of the image, we see quite a few strings associated with "Internet" and "HTTP." This is indicative of the malware having network connection capability, either communicating back to an IP or domain to pull down additional files or receive instructions.
TAKING A LOOK IN REMNUX
Pushing the file over to REMnux, there's some static analysis we can do here as well. ExifTool by Phil Harvey pulls the metadata from the file passed to it. If the data is available for the specimen being analyzed, it can offer details such as who authored the file. Running this can offer some high-level initial context.
Although we already took a look a strings in PeStudio, pestr searches for ASCII and Unicode strings, which can be useful in that it covers a broader swath of information. It also allows you to set a minimum string length in case you want to weed out some of the gibberish fluff surrounding useful information, or are specifically looking for information that would be in a longer string. You can also pipe the output to grep and filter based on a specific character pattern, such as "http" or "www" if looking for hardcoded domain names.
Looking at the pestr output, we can see some of the findings we discovered in PeStudio, and a bit more. We see Chinese (PRC), which may be indicative of the system language of the environment this was developed in. We also see references to DLLs and OCX extensions. OCX files are associated with ActiveX controls and can be linked to web pages. Another useful tool is capa. Capa was developed by Mandiant's FLARE team and highlights capabilities in executables. The output is very easy to read and takes analysis a step further by mapping the capabilities to known threat matrices such as MITRE's ATT&CK and Malware Behavior Catalog (MBC). Running it is as simple as typing capa filename.exe
Capa's output corroborates some of the information we saw in PeStudio, such that the executable reads and writes files and interacts with the registry. The last REMnux tool I'll highlight is Speakeasy. Speakeasy is also a Mandiant open-source tool and functions as a Windows emulator. It mimics a Windows environment so that the specimen can "run" without actually conducting dynamic analysis. To run it, simply type run_speakeasy.py -t filename.exe
In Speakeasy's output, we see references to the OCX files again, this time in literal string format. We also see the module 'CreateFileA' generating 'C:\Program Files\Common Files\whh02053.ocx' in the last string of the tool's output. Now not only do we know that the executable has file write capabilities, we know what one of the files is and where it may be written.
COMPILATION OF FINDINGS
In our static analysis of the file, we had the following findings:
The file was packed using UPX
Once unpacked, we confirmed that the file is a 32-bit portable executable
The file has the ability to:
Interact with the system registry and processes
Create, read, and write to files, and generates files with .OCX extensions (ActiveX controls)
File written: C:\Program Files\Common Files\whh02053.ocx
Open and interact with connections to the internet over HTTP
Evade debugging and analysis
While these findings are in no way an all-encompassing report, they help in starting to paint a picture of what this executable is doing and what its capabilities are. The details we gathered would help drive the dynamic analysis that would follow, and the great accomplishment is that we gathered this many details without even running the malware to begin with. Another important point to address is, while we could've easily just typed this hash into VirusTotal and known exactly what we were working with, that's not something that's achievable with every file. It's incredibly easy to force file hash changes and wind up with inconclusive results, leading to a dead end if the analyst doesn't have the ability to conduct static analysis like what we've outlined above. Also, it is not advised to upload malware samples to VirusTotal. Threat actors are known to monitor VirusTotal and see whether or not their malware has been submitted in order to determine whether or not they've been caught. Again, with how easy it is to change hashes, threat actors leverage this to uniquely identify campaigns where they're using the specimen; submitting this to VirusTotal would ring alarm bells on their end and highlight exactly which campaign has been observed and burned.
SO...WHAT IS KAZY?
The malware we analyzed in this iteration of the series is the Kazy trojan. Kazy emerged in the early 2010s and is known to operate as a downloader, downloading malicious files from a server and executing them on the infected endpoint.