Forensic Analysis of MUICache Files in Windows
As examiners, we often find ourselves wanting to know if a program was executed on a system, when it was executed on a system, or if a program or file ever existed on a system. While there are several components on modern Windows operating systems that can be reviewed to surface this information, there are times when malicious activity comes into play, which alters or erases the data stored within these operating system components. This activity potentially makes it difficult to determine if a program existed, was launched, and when. In this first of two installments in this series, we are going to examine the Multi-Lingual User Interface, otherwise known as the MUICache.
What is MUICache?
The MUICache is part of the Multilingual User Interface service in Windows and was first introduced with Windows 2000. The Multilingual User Interface serves to support the use of the Windows operating system across international markets; a key component of the MUICache is the idea of localization.
Localization addresses a variety of aspects of language support in the Windows operating system and applications to ensure the user interface is optimized for displaying various characters and symbols. This does not only address text-based data, but potentially icon shape, icon size, icon location, window arrangement, window configuration, and other aspects of a program that require some form of adjustment to accommodate the variety of characters humans use in our various languages.
One of the interesting aspects of MUICache is that we, as digital forensic examiners, are largely using this operating system artifact for a completely unintended purpose. The MUICache is a mechanism within the Windows operating system that ensures a positive user experience when that application is expected to be translated into different languages that are used around the globe. As a result of the function of MUICache, it is keeping a list of executables and storing them in a user-specific Windows Registry hive.
Programmatically this can provide a bit of a heavy lift, especially considering the number of applications on a typical Windows computer. In turn, this could lead to performance degradation as the multilingual service comes into play when an executable is launched. This is where the “cache” component of MUICache steps in to speed things along.
Why Worry About MUICache?
One of the great things about the Windows operating system is the number of artifacts we have as examiners that can help us profile user interaction with a system. These artifacts help paint a picture of what was done and when.
With so many artifacts to leverage in an examination, there is a need to understand them to help us determine what may have led to their being on the system. We should also recognize that there are often multiple ways a particular artifact comes to be in existence on a Windows computer.
Ideally, we do not approach an examination, locate one item out of the (hopefully) many available artifacts, and draw a conclusion saying the presence of this “thing” means some specific activity occurred. We are typically using a variety of artifacts, many of which help to corroborate one another, to tell the story of what a user may have been doing on a Windows computer and which programs they were interacting with.
As examiners, we recognize that many of the operating system artifacts we have come to leverage do not exist for the purposes we are using them for. They largely exist to support the user experience, either by offering performance increases or enhanced diagnostics and error reporting, which can be shared back with Microsoft or application developers. We are simply leveraging the information these artifacts contain—exploiting them in a sense—to help us derive what a user was doing on a Windows computer and how they were interacting with its installed applications.
One of the other great things about the variety of operating system artifacts we have come to leverage in the examination of a Windows operating system computer is that your typical user may have no idea they exist. This could mean evidence of program interaction can be left behind, even when the user may be taking steps to cover their tracks by leveraging something like the ever-popular CCleaner or uninstalling incriminating applications.
A Malware Infection Scenario
Another scenario that comes to mind regarding program execution is when investigating instances of malware infection. Many times, malware is written to evade detection, and this can be accomplished through a variety of methods. Sometimes detection evasion is accomplished by something as straightforward as deleting prefetch files referencing that a suspicious executable has run. Assuming appropriate user account permissions are in place.
What if the malware was only written to cover its tracks concerning some of the more well-known operating system components? What if the threat actor was not aware of all the various artifacts of the Windows operating system which may be sitting there, silently tracking and recording everything that was done on that system? These are oversimplifications but the idea is to point out that on a modern Windows computer, there are many operating system artifacts that detail the different executables that have run on that system. Some of those artifacts are well known and are go-to sources of information for digital forensic examiners in a typical case, while others are lesser-known—not just for digital forensic examiners, but your average Windows computer user or other threat actors who may be trying to cover their tracks.
What Should We Expect to See?
With a variety of mechanisms in place that track program execution, what should we expect to see on a normal system? What are we as examiners to conclude when something is not as expected?
In the case of program execution, when these various artifacts do not align with one another to tell the same story, we may very well be looking at a situation where malicious activity is at play and a user—or program—is trying to deceive us by taking steps to hide the true activity on a system. Therefore, when things are not as we expect them to be, we must try to determine the why behind them. Fortunately, the Windows Registry keeps track of a tremendous amount of useful information to help guide us in answering this question: Why?
Because the Windows Registry contains a significant amount of information, it can be overwhelming, and this can lead to situations where it is easy to misinterpret what an artifact means to an investigation. Another difficulty examiners will encounter regarding the Windows Registry is a result of its very nature. The data which comprises the Windows Registry is stored in several locations on disk, using a collection of Registry hives—both system-wide and user-specific.
Using Magnet AXIOM, we can review a variety of artifacts sourced from the different Registry hives on a Windows computer system using the Artifact explorer. The Artifact explorer presents information to examiners in an easily consumable manner and provides an effective way to quickly review data from a variety of evidence sources and locations.
We can also utilize the Registry explorer in AXIOM Examine to review the content of individual Registry hives in greater detail to verify Registry-sourced artifacts and to locate items that may not be presented for review in the Artifact explorer.
Through this two-part series on cache mechanisms in the Windows operating system, we can hopefully bring some clarity to the Windows Registry. In part one, we will be taking a look at the data contained within MUICache—which supports application user interface functioning in a global environment. In part two, we will be looking at application compatibility support offered through AmCache and Shimcache.
Collectively, these three caching features of the Windows operating system are perhaps lesser known, both to users and threat actors. This could mean finding information associated with one of these artifacts when more traditional artifacts of program execution have been removed from a system through some form of malicious activity.
For both posts, we will be using a Windows 10 computer image and RAM capture. If you would like to follow along, we are using the “HP Image” from the Magnet Summit 2022 Capture the Flag Contest you can download here, and a Windows 10 memory image available here.
MUICache Operation
MUICache data is populated by Explorer and is largely transparent to the user. When an executable is launched, MUICache references the file description contained within the executable’s resource section and populates that value in the USRClass.dat Registry hive for the user in Windows Vista and later versions. This is where MUICache gets interesting and potentially gives examiners data that may help to corroborate other information seen during a digital forensic investigation.
The file specification for a Windows executable file (also referred to as a portable executable or PE format), describes the various structures they may contain.
Of interest for this artifact is the presence of resource (.rsrc) sections. These resource sections typically contain data about the other resources an executable may need when reviewing that item in Explorer such as the intended program icon and program name when a user hovers the mouse pointer over it. Using Angus Johnson’s Resource Hacker and the executable file for Magnet AXIOM Process, we can see examples of these resource sections. The program icon, shown here:
One of the other resource sections is referred to as Version Info which typically contains information such as the company name or developer name for the executable, file name, file version information, copyright information, and product version, as shown here:
In the Windows Operating system, MUICache is retrieving the values listed in the Version Info resource sections for Company Name and File Description and storing that data in the UsrClass.dat Registry hive.
For example, when launching the executable for Magnet AXIOM Process, the values shown above:
VALUE “CompanyName”, “Magnet Forensics\xAE Inc.”
and
VALUE “FileDescription”, “Magnet AXIOM Process”
are retrieved from the Version Info resource section and populated in the MUICache entries on the system as:
MUICache Location
MUICache is stored in the UsrClass.dat Windows Registry hive. In addition to UscClass.dat, we are also interested in any associated transaction LOGs which may be present. For Windows Vista and later, UsrClass.dat is located at:
%SystemDrive%\Users\<username>\AppData\Local\Microsoft\Windows\usrClass.dat
If exporting for review in an external tool, be sure to collect any usrClass.dat.LOG# files
%SystemDrive%\Users\%username%\AppData\Local\Microsoft\Windows\UsrClass.dat.LOG1
%SystemDrive%\Users\%username%\AppData\Local\Microsoft\Windows\UsrClass.dat.LOG2
Transaction Logs
Transaction logs were first introduced with the Windows 2000 operating system and a revised log format debuted with Windows 8.1. Transaction logs are stored as separate files in the same directory on disk as their associated Registry hive and follow the naming convention of Registry_hive_name.LOG. In some instances, there will be more than one transaction log file with extensions similar to .LOG1 and .LOG2 where Windows is creating multiple transaction logs for a specific Registry hive.
It is important to know what your forensic tool of choice is doing regarding transaction logs for Registry hives. In AXIOM, artifacts sourced from Windows Registry hives and displayed in the Artifact explorer, as well as Registry hive content shown in the Registry explorer, will present the content of the active Registry hive with all transaction log data merged. Examiners wanting to see the Registry hive without transaction log data merged can utilize the File system explorer within AXIOM to export the specific Registry hive without associated transaction log(s) and add it back into the AXIOM case as a separate evidence item or review it with an external tool.
Like other Windows Registry hives, the UsrClass.dat hive contains many keys other than MUICache. To review MUICache data in AXIOM Examine, select the Registry explorer from the drop-down menu of the user interface.
Expand the entry for User hives then expand the entry for the username you are interested in. Finally, expand UsrClass.dat and navigate to:
\Local Settings\Software\Microsoft\Windows\Shell\MuiCache
and
\Local Settings\MuiCache\ [all subkeys]
Note if this were a live system, the full path would be:
HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache
and
HKEY_CURRENT_USER\Software\Classes\Local Settings\MuiCache\ [all subkeys]
Data
We can utilize the Artifact explorer in AXIOM Examine to simplify the review of data and then verify any items of interest using the Registry explorer within AXIOM Examine to see MUICache data as it appears in the UsrClass.dat Registry hive.
The MUICache artifact fragments shown in the Artifact Explorer of AXIOM Examine include the file name, file path the executable ran from, and a data column containing the File Description resource attribute from the Version Info resource section.
One thing to note: not included in MUICache data is a timestamp indicating when an executable ran. This information is simply not tracked by MUICache and would need to be determined through alternative methods.
Analysis
When adding an evidence source in AXIOM Process from a Windows computer, the MUICache artifact is included under the Computer artifacts, OPERATING SYSTEM artifact detail section and is selected by default. Artifacts parsed from MUICache will be available for review in the MUICache artifact category located under Operating System in AXIOM Examine.
Once processing is complete, in AXIOM Examine select the Artifact explorer from the drop-down menu on the Case Dashboard. Expand OPERATING SYSTEM from the Navigation pane on the left, and then choose the MUICache artifact category.
Once here, all the usual features available within AXIOM Examine to search, sort, and filter based on your investigative goals are available to you. For example, filtering on the File Path column to look for executables which launched from the user’s profile folder or searching for a specific executable by file name is easily accomplished.
What Can We Learn?
While the MUICache does not contain a tremendous amount of information, what it does contain can be useful in several ways in a digital forensic investigation.
If things are normal and as expected, the MUICache entries should have data that corresponds to what we see in other Windows operating system artifacts detailing executable launch, such as Windows Prefetch, helping to corroborate that a specific executable was launched on a system. Because the executable name is populated by MUICache from the Version Info resource section, it may be less likely to have been altered making it potentially more reliable in some cases and serving as a point of comparison to other operating system artifacts.
If a user has taken steps to cover their activity on a system, perhaps by renaming an executable, MUICache may still show the true name of the executable as shown in the FileDescription section of the Version Info resource section. Further, if a user has uninstalled an application that violates acceptable use, or one that was used for other nefarious purposes, it is possible the MUICache entries could still be present, proving the prior existence of that executable.
Finally, in malware examinations, the information contained in MUICache may be used to show that a specific executable ran on a system, including the path it ran from, even when that executable may no longer remain on the system.
Conclusion
I hope this first post reviewing artifacts located in the Windows MUICache has been useful. I welcome any questions or feedback, including suggestions for other artifacts you would like to see covered in upcoming posts (christopher.cone@magnetforensics.com).
In the next post, we’ll be covering two components of the Windows application compatibility functionality provided by AmCache and ShimCache.