In 2017, Mandiant responded to multiple incidents we attribute to
FIN7, a financially motivated threat group associated with malicious
operations dating back to 2015. Throughout the various environments,
FIN7 leveraged the CARBANAK backdoor, which this group has used in
A unique aspect of the incidents was how the group installed the
CARBANAK backdoor for persistent access. Mandiant identified that the
group leveraged an application shim database to achieve persistence on
systems in multiple environments. The shim injected a malicious
in-memory patch into the Services Control Manager (“services.exe”)
process, and then spawned a CARBANAK backdoor process.
Mandiant identified that FIN7 also used this technique to install a
payment card harvesting utility for persistent access. This was a
departure from FIN7’s previous approach of installing a malicious
Windows service for process injection and persistent access.
Application Compatibility Shims Background
According to Microsoft, an application compatibility shim is
a small library that transparently intercepts an API (via hooking), changes
the parameters passed, handles the operation itself, or
redirects the operation elsewhere, such as additional code stored on a
system. Today, shims are mainly used for compatibility purposes for
legacy applications. While shims serve a legitimate purpose, they can
also be used in a malicious manner. Mandiant consultants previously
discussed shim databases at both BruCon
Shim Database Registration
There are multiple ways to register a shim database on a system. One
technique is to use the built-in “sdbinst.exe” command line
tool. Figure 1 displays the two registry keys created when a shim is
registered with the “sdbinst.exe” utility.
Figure 1: Shim database registry keys
Once a shim database has been registered on a system, the shim
database file (“.sdb” file extension) will be copied to the
“C:\Windows\AppPatch\Custom” directory for 32-bit shims or
“C:\Windows\AppPatch\Custom\Custom64” directory for 64-bit shims.
Malicious Shim Database Installation
To install and register the malicious shim database on a system,
FIN7 used a custom Base64 encoded PowerShell script, which ran the
“sdbinst.exe” utility to register a custom shim database file
containing a patch onto a system. Figure 2 provides a decoded excerpt
from a recovered FIN7 PowerShell script showing the parameters for
Figure 2: Excerpt from a FIN7 PowerShell script
to install a custom shim
FIN7 used various naming conventions for the shim database files
that were installed and registered on systems with the “sdbinst.exe”
utility. A common observance was the creation of a shim database file
with a “.tmp” file extension (Figure 3).
Figure 3: Malicious shim database example
Upon registering the custom shim database on a system, a file named
with a random GUID and an “.sdb” extension was written to the 64-bit
shim database default directory, as shown in Figure 4. The registered
shim database file had the same MD5 hash as the file that was
initially created in the “C:\Windows\Temp” directory.
Figure 4: Shim database after registration
In addition, specific registry keys were created that correlated to
the shim database registration. Figure 5 shows the keys and values
related to this shim installation.
Figure 5: Shim database registry keys
The database description used for the shim database registration,
“Microsoft KB2832077” was interesting because this KB number was not a
published Microsoft Knowledge Base patch. This description (shown in
Figure 6) appeared in the listing of installed programs within the
Windows Control Panel on the compromised system.
Figure 6: Shim database as an installed application
Malicious Shim Database Details
During the investigations, Mandiant observed that FIN7 used a custom
shim database to patch both the 32-bit and 64-bit versions of
“services.exe” with their CARBANAK payload. This occurred when the
“services.exe” process executed at startup. The shim database file
contained shellcode for a first stage loader that obtained an
additional shellcode payload stored in a registry key. The second
stage shellcode launched the CARBANAK DLL (stored in a registry key),
which spawned an instance of Service Host (“svchost.exe”) and injected
itself into that process.
Figure 7 shows a parsed shim
database file that was leveraged by FIN7.
Figure 7: Parsed shim database file
For the first stage loader, the patch overwrote the
“ScRegisterTCPEndpoint” function at relative virtual address (RVA)
“0x0001407c” within the services.exe process with the malicious
shellcode from the shim database file.
The new “ScRegisterTCPEndpoint” function (shellcode) contained a
reference to the path of “\REGISTRY\MACHINE\SOFTWARE\Microsoft\DRM”,
which is a registry location where additional malicious shellcode and
the CARBANAK DLL payload was stored on the system.
Figure 8 provides an excerpt of the parsed patch structure within
the recovered shim database file.
Figure 8: Parsed patch structure from the shim
The shellcode stored within the registry path
“HKLM\SOFTWARE\Microsoft\DRM” used the API function
“RtlDecompressBuffer” to decompress the payload. It then slept for
four minutes before calling the CARBANAK DLL payload’s entry point on
the system. Once loaded in memory, it created a new process named
“svchost.exe” that contained the CARBANAK DLL.
Bringing it Together
Figure 9 provides a high-level overview of a shim database being
leveraged as a persistent mechanism for utilizing an in-memory patch,
injecting shellcode into the 64-bit version of “services.exe”.
Figure 9: Shim database code injection process
Mandiant recommends the following to detect malicious application
shimming in an environment:
- Monitor for new shim database files created in the default
shim database directories of “C:\Windows\AppPatch\Custom” and
- Monitor for registry
key creation and/or modification events for the keys of
process execution events and command line arguments for malicious
use of the “sdbinst.exe” utility