Loading story…
Public research described a Windows shellcode execution method linked to Lazarus Group that stores payloads as UUID-formatted strings, decodes them with the Windows API UuidFromStringA, and writes the resulting bytes directly into executable memory. A proof of concept showed the payload being reconstructed after memory allocation with VirtualAlloc, while related reporting said Lazarus used HeapCreate and HeapAlloc in observed operations.
The reconstructed shellcode was then executed indirectly through callback-based Windows APIs, including EnumChildWindows and EnumDesktopsA, while separate analysis associated Lazarus with using EnumSystemLocalesA for the same purpose. The technique highlights a stealth-oriented approach that blends payload decoding with legitimate system functions to launch in-memory code and reduce straightforward static detection.
TTPs, infrastructure, and targeting history in one profile.
2 events from the most recent confirmed update back to the earliest known activity.
A cocomelonc post published a Windows proof of concept that decodes UUID-formatted payload chunks with UuidFromStringA into executable memory and runs them via callback APIs such as EnumChildWindows. The post states the approach is similar to a method associated with Lazarus Group and includes code and a helper script for converting payloads into UUID strings.
NCC Group RIFT published research analyzing a shellcode execution method associated with Lazarus Group. The later cocomelonc article explicitly references this NCC Group analysis as the basis for the described technique.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
See this adversary's TTPs, infrastructure, and targeting history, correlated against your exposure.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Elastic Security Labs analyzed a **GULOADER** (CloudEyE) campaign in which the shellcode downloader was delivered in an NSIS installer and used `System.dll` to allocate and execute encrypted payloads. The malware invoked callback-capable Windows APIs, including `EnumResourceTypesA` and `CallWindowProcW`, to launch its shellcode. GULOADER expanded its vectored exception handler (VEH)-based anti-analysis protections by handling privileged- and illegal-instruction exceptions, checking for hardware breakpoints, and altering the instruction pointer through the exception `CONTEXT` record to obscure control flow. Windows supplies VEH handlers with `EXCEPTION_POINTERS`, which contains an `EXCEPTION_RECORD` and processor-state `CONTEXT`; the malware abuses this state to redirect execution. Elastic published exception-tracing and patching techniques, YARA rules, and campaign observables to support detection and reverse engineering.
Sep 9, 2026
A public technical walkthrough detailed **module stomping**, a Windows code-injection technique that executes shellcode by overwriting the `.text` section and entry point of a legitimate sacrificial DLL instead of allocating new executable memory. The write-up showed how an attacker can map a DLL as a `SEC_IMAGE` section with native APIs such as `NtCreateSection` and `NtMapViewOfSection`, confirm that the payload fits between the DLL entry point and the end of the code section, replace the entry point with shellcode, and launch execution with thread-creation APIs including `NtCreateThreadEx`. The material also described a remote variant in which a DLL such as `shell32.dll` is loaded into another process, its entry point is located with process-memory and Toolhelp APIs, and that entry point is overwritten before execution is triggered with `CreateRemoteThread`. Examples cited `combase.dll` and `shell32.dll` as sacrificial modules and noted that manual mapping may help avoid **Control Flow Guard** issues that can arise with `LoadLibrary`, making the published proof of concept directly relevant to defenders tracking stealthy malware tradecraft on Windows.
Jul 29, 2026
Security research detailed a Windows code-injection technique that abuses Portable Executable (PE) sections marked readable, writable, executable, and shared (`RWX-S`) to place shellcode into another process without relying on common cross-process memory operations such as `WriteProcessMemory`. The method takes advantage of PE shared sections so that changes made in one process can be reflected in another process loading the same image in the same session, potentially reducing visibility to kernel-observed telemetry sources such as Microsoft-Windows-Threat-Intelligence ETW and `ObRegisterCallbacks`. The research said attackers could patch a host binary whose entry point resides inside an `RWX-S` section, causing shellcode to execute when the remote process loads the binary. Using VirusTotal Retrohunt and YARA to identify candidate files, the author found more than 10,000 unsigned matches overall, including 99 unsigned x64 samples, along with roughly 15 uniquely signed binaries with valid Authenticode signatures, only five of them x64. Microsoft PE format documentation provides the structural context for how such shared sections are defined, while the findings suggest these binaries are uncommon enough to give defenders a relatively high-fidelity detection opportunity despite their offensive value.
Aug 15, 2026