You arrive at your desk, fire up your computer, and open up one of your daily applications, such as email. Could this simple act execute malicious code onto your computer?
It could, using Application Shims.
This post for threat hunters will explore how to hunt for malicious Shim installation and execution. We will talk through what Application Shims are and how they are used, how to install them, explore how a threat actor might manipulate them, and how to hunt for the key indicators that demonstrate evidence of Shim compromise.
What are Application Shims?
Application Shims were created to allow backward compatibility of applications to help ensure that applications continued to function properly after updates to Windows and Windows APIs. These Shims allow developers to apply fixes to applications that were created for legacy Windows versions and to ensure that they will also work with the latest Windows version without rewriting the code. You can read more about how Shims work here and there is also an excellent whitepaper on this topic by Sean Pierce.
There are a number of functions that can be abused for malicious purposes, as Sean shared:
- Manipulating a process with redirections using ‘VirtualRegistry’, ‘CorrectFilePaths’, ’VirtualizeDeleteFile’, ‘RedirectShortcut’ and ‘APILogger’.
- Persistence and Trojanizing using ‘InjectDll’, ‘LoadLibraryRedirect’, ‘RedirectShortcut’,‘RedirectEXE’,‘ShimViaEAT’, ‘LoadLibraryfromCWD’ and much more can be accomplished with in-memory patching.
- Disabling defenses using ‘DisableWindowsDefender’, ‘DisableASLR’,’DisableAdvancedRPCClientHardening’, ‘DisableSeh’ and ‘DisableNX’.
In this post we will be using the InjectDll fix to demonstrate how a DLL can be loaded within Firefox.
Creating a Shim
To create a payload for Application Shims, we will be using the Compatibility Administrator tool – which is part of the Application Compatibility Toolkit – and specifically the “InjectDll” option that Shims provide to preload a DLL into an application. This option is only available for 32-bit fixes, so in this case, we found that Firefox is a great target because it is a 32-bit application and doesn’t have Control Flow Guard and many users have Firefox installed.
We won’t walk through the process of creating the Shims because there is already an excellent guide by actae0n; however, a high level screenshot is below. This process will generate our malicious SDB (Shim Database) file.
Installing our SDB
There are two main ways to install a Shim, either using Microsoft’s built-in sdbinst utility or by directly modifying the Windows registry.
Installation is simple using sdbinst – all you have to do is supply the sdb on the command line. This technique will require a high integrity/administrator shell:
The disadvantage for attackers using this tool is that it will leave an entry in the Add/Remove Programs list.
To avoid leaving that footprint, you can instead manually create the Shim registry keys or use a tool like sdb-explorer. In the next section we will look at how this can be achieved.
Firefoxing, you say?
To demonstrate a practical attack we created a Powershell script to download both our SDB file and a DLL payload. It would then install the Shim for Firefox by adding the necessary registry keys.
After Firefox is executed, the Shim will inject our malicious DLL into the process and execute our code. You can see from the image below that our ‘Malicious.dll’ was successfully loaded into the module chain and calc executed.
Like other persistence mechanisms, as a defender we can either focus on detecting the initial installation of the persistence or the persistence artefacts themselves. In the previous example the download and installation was completed using Powershell, which provides a great place to begin our investigation.
Process execution and network analysis
We used Sysmon to investigate events logged for this activity and you can see that the first PowerShell command was logged with Event ID 1, as well as Event ID 4104 for the second PS command if you have enabled the PS Logging.
You can also see the anomalous process spawned out of Firefox that loaded our DLL and executed the payload – in this case, the calculator.
In the event of the attacker using sdbinst.exe for installation, you’ll see an event like below:
The network connection event log also shows an entry for the outbound connection coming from PowerShell.
Another detection technique here is the monitoring of anomalous DLL load events. In this instance you would see Firefox loading our malicious.dll. Path, name, hash or a combination could provide a nice way to spot anomalous DLL loads.
Look out for registry creation
Whenever a custom Shim is installed, entries will be created in the following registry paths:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Custom\ HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB\
You can find the path of the custom SDB file in the ‘DatabasePath’ value from the ‘..\InstalledSDB\’ registry key. Sysmon is able to detect registry key creation, which will be logged with Event ID 12 as below:
PowerShell can be used at scale to retrieve these keys and least frequency analysis of the DatabasePath can highlight anomalous sdb files.
Analyzing the Shim database file
From an analysis perspective it is possible to extract the data from the SDB file by using a tool such as “python-sdb”. From the output below, you can see that it is utilizing InjectDll and pointing to malicious.dll in the %PROGRAMDATA% directory.
It is worth noting that many different types of Shim can be used. Here we used InjectDLL to inject our malicious DLL into a 32-bit process, but there have been multiple real world threats – such as BlackEnergy, Gootkit and Dridex – that have used “RedirectEXE” instead to execute additional processes.
The FIN7 APT group has also previously used Shims that when executed would patch the Services Control Manager (“services.exe”) process in order to execute a secondary payload stored in the registry. You can read more about this here.
Conclusion
Although this persistence technique is not new, its stealthy approach and rarity means defenders are often unaware of its existence and use.
It’s important for threat hunters to understand how Shims can be abused, what custom Shims your organization currently uses, and how to both detect and analyze anomalous Shims being installed in order to stop real world attackers that might use such persistence.
Categories