Phantom DLL

Phantom DLL provided a Windows detonation service and asked for one output file. The service accepted an uploaded library, placed it into the victim environment, and launched an application that searched for a familiar Windows multimedia DLL.

The key observation was the loaded module name: the uploaded file was being treated as winmm.dll. That turned the task into a controlled DLL search-order hijack.

Build for the loader you actually have

We produced both 32-bit and 64-bit probes, exported common entry points, and kept the initialization path deliberately small. The 64-bit build matched the detonation process.

BOOL WINAPI DllMain(HINSTANCE module, DWORD reason, LPVOID reserved) {
    if (reason == DLL_PROCESS_ATTACH) {
        DisableThreadLibraryCalls(module);
        run_probe();
    }
    return TRUE;
}

Heavy work inside DllMain risks loader-lock deadlocks. The probe performed only bounded file checks and a single output write, avoiding networking, child processes, and long waits.

Confirm execution before searching

The first build wrote process and module context to the required output. That confirmed three things:

1. the DLL architecture was correct;
2. DllMain executed in the target process;
3. the service returned the generated output file.

Only then did we add a small list of likely evidence locations. The loaded probe found the challenge artifact and copied its content into the required result file.

Takeaway

In a detonation challenge, begin with the loader contract. A minimal execution proof is more valuable than a complicated payload: confirm architecture, module name, entry-point execution, and output handling before adding discovery logic.

Event page: LIGA CTF 2026.