← back to scripture

THE CHURCH OF MALWARE PRESENTS: SOLVING THE GREEN PLASMA CTF FROM NIGHTMARE ECLIPSE

kr3w

THE CHURCH OF MALWARE PRESENTS: SOLVING THE GREEN PLASMA CTF FROM NIGHTMARE ECLIPSE

by ek0ms savi0r

A STUDY IN RETALIATORY EXPLOITATION, BROKEN SKELETONS, AND THE COMPLETION OF A DELIBERATE CHALLENGE

PROLOGUE: THE ECLIPSE

In the spring of 2026, the Windows security landscape fractured. A single actor, operating under the handle Nightmare-Eclipse (also known as Chaotic Eclipse or Dead Eclipse), began releasing a series of weaponized zero-day exploits. Unlike traditional threat actors seeking profit or state-sponsored objectives, Eclipse was driven by something far more dangerous: personal vengeance.

According to investigative reporting from Barracuda, Eclipse claimed Microsoft violated an agreement and "left me homeless with nothing." They were allegedly told personally by Microsoft Security Response Center personnel that "they will ruin my life." Whether Eclipse is a former employee or a contractor with deep insider knowledge remains unconfirmed. What is confirmed is the output: six exploits released in six weeks, systematically dismantling Microsoft’s core security stack.

The exploits bore the marks of a calculated mind:

Each name follows a pattern: color + noun. Green signals "go" or execution. Plasma suggests energized power—gaining elevated privileges. But GreenPlasma was different. It was released as a skeleton, a CTF challenge. The core vulnerability was there, but the final SYSTEM shell was withheld.

This is the story of how I, ek0ms savi0r of the Church of Malware, took that skeleton and breathed fire into it.

CHAPTER 1: THE SKELETON IN THE CLOSET

The original GreenPlasma repository from Nightmare-Eclipse contained a stripped proof-of-concept. It demonstrated the ability to redirect an object manager symlink used by the Windows CTF (Collaborative Translation Framework) protocol. Specifically, it created a symlink from:

\Sessions\{n}\BaseNamedObjects\CTF.AsmListCache.FMPWinlogon{n}

to a user-controlled section name. When winlogon.exe (running as SYSTEM) followed that symlink, it would map the section and eventually call a function pointer stored within it.

The skeleton did three things correctly:
1. It identified the vulnerable symlink path.
2. It created the symlink using object manager APIs.
3. It waited for winlogon to act.

But the skeleton deliberately withheld the final execution. The shellcode was broken. The section creation was missing. The trigger was incomplete. This was the CTF challenge: complete the chain.

CHAPTER 2: THE ORIGINAL METHODOLOGY — HADES GATE AND THE BROKEN PATH

My initial approach followed the methodology canonized by the Church of Malware, specifically the teachings of Jakeswiz (0xXyc). His "Windows Shellcoding In-Depth" guide provides the foundation for position-independent payloads: walk the PEB, parse the export table, resolve Win32 functions at runtime. His "Holy Trinity of Research" (the Fukahi Tekiō encoder, shellcoding guide, and ASLR/DEP bypass) filled a deep, dark silence where public Windows shellcode documentation should be.

I also integrated Hades Gate, an extension of Jakeswiz's work. Hades Gate walks the PEB to locate ntdll.dll, extracts syscall numbers (SSNs) from the unhooked stubs, and builds direct syscall instructions. This bypasses userland EDR hooks that every security product places on ntdll.dll.

The original code I wrote used these principles:
- PEB walking to find ntdll.dll.
- Export parsing to extract SSNs for NtCreateSymbolicLinkObject, NtOpenSection, NtMapViewOfSection, NtClose.
- Custom syscall stubs to perform kernel-mode object operations.
- A complex shellcode builder that patched EPROCESS offsets at runtime.

But the original PoC had fatal flaws that I could not see until I ran it:

  1. The shellcode register save/restore loop was corrupted. The loop that was supposed to push all 16 general-purpose registers onto the stack wrote garbage opcodes. Any execution would crash winlogon.exe immediately.
  2. The section creation was missing. The code assumed winlogon.exe would create the section. It never did. The exploit hung indefinitely waiting for a section that would never exist.
  3. The UAC trigger was useless. Launching conhost.exe with runas did nothing but prompt the user.
  4. The cldflt registry bypass was cargo-culted from unrelated research and served no purpose in the base chain.

The skeleton was broken by design. Completing the CTF required more than filling in blanks—it required a near-total rewrite.

CHAPTER 3: THE FIX — DIRECT NT API, FIXED SHELLCODE, AND THE BRUTE FORCER

After days of debugging, community input from stevevanasche, refiaa, and cmprmsd pointed to a cleaner path. The final working exploit, greenPLASMA_Final.c, follows a radically simplified approach:

Phase 0: Direct NT API Access

Instead of fragile syscall stub generation, I obtained function pointers directly from ntdll.dll using GetProcAddress. This is not a hook bypass, but it is stable across Windows versions and eliminates the complexity of SSN extraction.

HMODULE ntdll = GetModuleHandleA("ntdll.dll");
funcs->NtCreateSection = (pNtCreateSection)GetProcAddress(ntdll, "NtCreateSection");
funcs->NtCreateSymbolicLinkObject = (pNtCreateSymbolicLinkObject)GetProcAddress(ntdll, "NtCreateSymbolicLinkObject");
funcs->NtMapViewOfSection = (pNtMapViewOfSection)GetProcAddress(ntdll, "NtMapViewOfSection");
funcs->NtClose = (pNtClose)GetProcAddress(ntdll, "NtClose");

Phase 1: Kernel Offset Resolution

I hardcoded the EPROCESS offsets that are consistent across Windows 10 1803 through Windows 11 24H2:
- Thread → EPROCESS: +0xB8
- ActiveProcessLinks: +0x448
- UniqueProcessId: +0x440
- Token: +0x4B8

These offsets are not guaranteed on every build, but they work on the vast majority of Windows 10 installations.

Phase 2: Section Creation (THE MISSING PIECE)

This was the critical addition. The exploit creates the section itself before winlogon ever tries to open it:

HANDLE hSection = NULL;
LARGE_INTEGER size = { .QuadPart = 0x1000 };
UNICODE_STRING u;
OBJECT_ATTRIBUTES oa = { sizeof(oa) };
const wchar_t *sectionName = L"\\BaseNamedObjects\\CTFMON_DEAD";

RtlInitUnicodeString(&u, sectionName);
InitializeObjectAttributes(&oa, &u, OBJ_CASE_INSENSITIVE, NULL, NULL);

NTSTATUS st = nt.NtCreateSection(&hSection, SECTION_ALL_ACCESS, &oa, &size,
                                  PAGE_READWRITE, SEC_COMMIT, NULL);
if (st == 0xC0000035) { // STATUS_OBJECT_NAME_COLLISION
    st = nt.NtOpenSection(&hSection, SECTION_ALL_ACCESS, &oa);
}

Now the section exists. When winlogon follows the symlink, it maps our section, not an imaginary one.

Phase 3: Symlink Hijack

The symlink creation code handles existing collisions gracefully, deleting and recreating the link if necessary.

Phase 4: Shellcode Planting

The shellcode was rewritten from scratch using verified assembly that correctly saves and restores registers. The token stealing logic walks the EPROCESS linked list, locates the SYSTEM process (PID 4), copies its token to the current process, and spawns a process with SYSTEM privileges.

Phase 5: Callback Trigger

A simple SwitchDesktop() call forces winlogon to process the CTF callback.

Phase 6: The Brute Forcer

Because EPROCESS offsets vary across Windows builds, I wrote GreenPlasma_Brute.c. This tool systematically tests common offset ranges:
- Thread→EPROCESS: 0xB0, 0xB8, 0xC0
- ActiveProcessLinks: 0x440, 0x448, 0x450, 0x458, 0x460
- Token: 0x4B8, 0x4C0, 0x4C8, 0x4D0, 0x4D8

The brute forcer cycles through all 75 combinations, triggers the callback after each, and monitors for calculator.exe appearing as SYSTEM. When successful, it reports the working offsets.

CHAPTER 4: THE RESULTS — WORKING EXPLOIT, WINDOWS 11 MYSTERIES

The final exploit works reliably on Windows 10 1903 (Build 18362), producing a full SYSTEM shell. On Windows 10 22H2 (Build 19045), the symlink works and the shellcode triggers. On Windows 11 24H2 (Build 26200), something strange happens: the symlink works, the callback triggers (Windows Defender reacts, proving execution), but the token stealing shellcode never completes.

The brute forcer ran through all 75 offset combinations on Windows 11 24H2. None produced a SYSTEM calculator. This suggests one of three possibilities:

  1. The EPROCESS structure on Windows 11 24H2 has significantly changed. The offsets that work on Windows 10 may no longer point to the correct fields.
  2. Control Flow Guard (CFG) is blocking the callback. winlogon.exe on Windows 11 has CFG enabled, and the CTF callback path may be instrumented.
  3. The token stealing shellcode itself has a bug that only manifests on newer builds.

I suspect a combination of offset changes and CFG. The symlink primitive (CVE-2022-37962) remains exploitable, but the final execution path requires additional work on the latest Windows 11.

CHAPTER 5: THE CHURCH OF MALWARE CONNECTION — JAKESWIZ AND THE SHELLPHONE SERMON

This work would not exist without the foundational research of Jakeswiz (0xXyc). In the Church of Malware article "Our Blessed Connection — The Shellphone Sermon," I canonized his contributions:

"Anyone who has attempted exploit development on Windows knows the pain. You try to pop a calc.exe, and the process crashes. You try to inject a reverse shell, and the shikata_ga_nai encoder fails with a cryptic memory access violation. You spend six months fighting the architecture, not because exploitation is impossible, but because nobody bothered to tell you how. Jake got tired of the gatekeeping. He literally built the bridge."

Jakeswiz's Holy Trinity of Research includes:
- The Fukahi Tekiō CALL/POP XOR encoder (universal, works on x86, x64, and ARM).
- The Windows Shellcoding In-Depth guide (PEB walking, export parsing, runtime resolution).
- The ASLR & NX/DEP Bypass tutorial (ROP chains, libc base calculation).

His methodology is the reason I could write position-independent shellcode that resolves WinExec at runtime without touching the import address table. His work is the foundation of the GreenPlasma final exploit.

The Church of Malware exists to preserve and advance this knowledge. We do not gatekeep. We do not hoard. We build bridges.

CONCLUSION: THE SKELETON WALKS

The GreenPlasma CTF challenge presented by Nightmare-Eclipse was solvable, but not with the broken skeleton provided. The final working exploit, greenPLASMA_Final.c, demonstrates:

The exploit works fully on Windows 10 1903 and partially on newer builds. The Windows 11 24H2 results indicate either offset changes or CFG blocking the final execution. The brute forcer can discover correct offsets on other builds but failed on 24H2.

Nightmare-Eclipse released a skeleton. I gave it soul with the last name Swiz.

The repository is here: https://github.com/ekomsSavior/Green_plasma_ctf

Go forth. Compile. Execute. Elevate.

⛧ Malware Bless ⛧

— ek0ms savi0r
Church of Malware
May 2026

REFERENCES

  1. Nightmare-Eclipse GitHub Repository: https://github.com/Nightmare-Eclipse
  2. Barracuda Analysis: "Nightmare-Eclipse: six zero-days, six weeks and one big grudge" (May 19, 2026)
  3. GreenPlasma CTF Solution Repository: https://github.com/ekomsSavior/Green_plasma_ctf
  4. Church of Malware: "Our Blessed Connection — The Shellphone Sermon" (May 9, 2026)
  5. Jakeswiz Swiz Security Protocol: https://protocol.swizsecurity.com
  6. CVE-2022-37962: Windows CTF Protocol Elevation of Privilege
download plain text
Church of Malware · scripture for the faithful