Security-X

Forum Security-X => News => Discussion démarrée par: igor51 le août 27, 2018, 19:00:27

Titre: [FireEye]To SDB, Or Not To SDB: FIN7 Leveraging Shim Databases for Persistence
Posté par: igor51 le août 27, 2018, 19:00:27
To SDB, Or Not To SDB: FIN7 Leveraging Shim Databases for Persistence

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
  previous operations.


 

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),     href="https://blogs.technet.microsoft.com/askperf/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff/">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   href="http://files.brucon.org/2015/Tomczak_and_Ballenthin_Shims_for_the_Win.pdf">BruCon
  and BlackHat.


 

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
  this command.


 


 
  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   href="https://github.com/williballenthin/python-sdb">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
    database file


 

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


 

Detection


 

Mandiant recommends the following to detect malicious application
  shimming in an environment:


 
  1. Monitor for new shim database files created in the default
        shim database directories of “C:\Windows\AppPatch\Custom” and
      “C:\Windows\AppPatch\Custom\Custom64”
  2. Monitor for registry
        key creation and/or modification events for the keys of
        “HKLM\SOFTWARE\Microsoft\Windows
        NT\CurrentVersion\AppCompatFlags\Custom” and
        “HKLM\SOFTWARE\Microsoft\Windows
      NT\CurrentVersion\AppCompatFlags\InstalledSDB”
  3. Monitor
        process execution events and command line arguments for malicious
        use of the “sdbinst.exe” utility 

Source: To SDB, Or Not To SDB: FIN7 Leveraging Shim Databases for Persistence (http://)