FaceDancer: An exploitation tool aimed at creating hijackable, proxy-based DLLs

FaceDancer

FaceDancer is an exploitation tool aimed at creating hijackable, proxy-based DLLs. FaceDancer performs two main functions:

• Recon: Scans a given DLL to create the export definition file for proxying.
• Attack: Creates a malicious DLL containing shellcode that can proxy valid function requests to the legitimate DLL.

FaceDancer contains numerous methods for performing DLL hijacking. These DLLs take advantage of either weak permissions on installation folders or COM-based system DLL image loading to load a malicious version of a legitimate DLL. Once loaded, the DLL executes the embedded shellcode while proxying valid requests for DLL functions to the legitimate DLL. This is done using a .def file to map the valid requests to the correct DLL, allowing a low-privilege user to proxy a legitimate DLL through a malicious one. This bypasses application whitelisting controls as FaceDancer targets native processes needed for standard operation, making it effective for initial access or persistence.

FaceDancer contains zero evasion techniques. FaceDancer’s sole focus is discovering and generating DLLs for proxying. It is important that the inputted DLL contains all the necessary evasion techniques. For more information about the techniques and how they are discovered, please see my blog.

Attack Methods

DLL Based Proxy

At a high level, this involves exploiting DLLs that reside in folders that are not properly protected when installed, allowing an attacker to abuse the Load Image operation when the application is launched via DLL proxying. The overarching issue is that when Microsoft Teams is configured with an account, the application installs some additional plugins (including an Outlook plugin). Some of these plugins are installed in the user’s AppData folder with overly permissive permissions (i.e., write permission). Because of this, an attacker can rename a valid DLL in one of these directories that a process loads when it first launches and place their own malicious DLL in the same folder to have it automatically load and execute. This does not require admin privileges.

Proxying Function Requests

Using definition files (.def), which are text files containing one or more module statements that describe various attributes of a DLL, we can define all the exported functions and proxy them to the legitimate DLL that contains the requested functions. By using an export.def file, we can rename the legitimate DLL to whatever we want (in the example below, we append -old to the name), place our DLL in the same folder, and when a process loads it, our DLL will proxy any requests for one of the DLL’s functions to the legitimate one.

    EXPORTS
    ?IsZero@UUID@Authentication@Microsoft@@QEBA_NXZ=OneAuth-old.?IsZero@UUID@Authentication@Microsoft@@QEBA_NXZ @1
    GetLastOneAuthError=OneAuth-old.GetLastOneAuthError @2
    InitializeTelemetryCallbacks=OneAuth-old.InitializeTelemetryCallbacks @3

Because of this only one DLL is ever loaded (not OneAuth and OneAuth-legitmate) but when we look at the DLL’s export functions we can see that each of the proxyed functions call back to OneAuth-legitmate.dll.

COM based Proxying

COM-based DLL proxying takes a different approach. It exploits dependencies in numerous native Windows and third-party applications. When executed, as these processes start up, they query the registry for COM objects to find the path to certain system DLLs to load. What makes these requests interesting is that they first check the Current User (HKCU) section of the registry. If they are unable to find the values there, they fail over to another section of the registry where the entries exist.

By creating the COM entries they look for, we can control which DLLs they load. Using the same proxy technique mentioned previously, we can load a DLL from anywhere as a system DLL and still proxy the traffic to the valid system DLL that resides in system32. This ensures there is no disruption to the process’s operation by still providing the valid functions. This all can be done as a low-privilege user without needing any privilege escalation or elevated permissions.

It works against Microsoft’s WindowsApp-based applications, including the new versions of Outlook (olk.exe) and Teams (ms-teams.exe). Applications in this folder are blocked even from Administrators. Attempting to access the folder to view the contents results in denied access, even when running as an Administrator.

This makes sideloading into these applications extremely difficult; however, they still rely on COM objects to load DLLs.

Install & Use