Loading story…
A Windows PE demonstration shows that Thread Local Storage (TLS) callbacks execute during process initialization before the executable entry point and C main. MinGW-w64 callback pointers placed in .CRT$XLB and .CRT$XLBB invoke two callbacks in order, producing 12 when both return normally. The first example ran raw x64 MessageBox payload through EnumDesktopsA, but its thread-exit behavior could end the initializing thread before the second callback and main executed; a revised payload restored the stack and returned normally, allowing initialization to complete.
TLS callbacks are legitimate PE and runtime infrastructure, but they can conceal behavior from analysts who begin debugging only at main. Defenders should inspect the PE TLS directory and callback-address array, then assess the callback code and its execution effects rather than treating TLS callback presence alone as malicious. Because this code runs amid loader initialization, unsafe operations and synchronization can also cause deadlocks or crashes under the loader lock; Microsoft recommends deferring complex initialization outside loader-managed entry paths.
Get the actors, campaigns, and ATT&CK mapping behind it.
3 events from the most recent confirmed update back to the earliest known activity.
A revised hack3 TLS-callback example resolved MessageBoxA through GetModuleHandleA and GetProcAddress, passed it to a callback-compatible EnumDesktopsA payload, and returned normally after displaying its dialog. This allowed the second TLS callback and main to execute, unlike the earlier thread-exiting payload path.
A MinGW-w64 PE experiment registered two TLS callbacks in .CRT$XLB and .CRT$XLBB, demonstrating that they run on the initializing thread before the normal entry-point and C main path; when both return normally, their recorded order is 12. The material also showed that an initial raw payload invoked from a callback could exit the initializing thread and prevent later callback and main execution.
An educational Windows PE experiment showed two ways to add 16 MiB without changing a program's primary MessageBox behavior: an initialized .bloat section and a post-section overlay of repeated bytes. The material described structural, signature, entropy, and context-based checks for investigating such padding rather than treating file size as malicious by itself.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
4 references tracked. Mallory keeps watching after this page renders.
malware.news
Open sourcecocomelonc.github.io
Open sourcecocomelonc.github.io
Open sourcelearn.microsoft.com
Open sourceMap 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.
Security research and malware-development writeups detailed a Windows evasion technique that avoids standard loader APIs such as **`GetProcAddress`** and **`GetModuleHandle`** by manually walking the **Process Environment Block (PEB)** and parsing DLL export tables. The approach resolves modules like **`kernel32.dll`** and **`user32.dll`** at runtime, including from encrypted strings, to reduce obvious API references in binaries and make static or behavioral detection more difficult. Microsoft’s documentation for **`GetProcAddress`** provides the baseline behavior that these custom implementations are designed to replace. One proof of concept showed a custom `GetProcAddress` implementation that located **`MessageBoxA`** dynamically on Windows 10 x64, while another demonstrated finding **`kernel32.dll`** in assembly-style code and resolving exports by hash before allocating memory and launching a benign payload with **`CreateThread`**. The authors framed the method as malware and red-team tradecraft, linked it to **MITRE ATT&CK `T1027`**, and noted similarities to techniques seen in **Conti ransomware** source code, underscoring how manual API resolution can help malicious code lower its detection footprint.
Aug 15, 2026
Elastic Security Labs reverse engineered Microsoft Time Travel Debugging (TTD), a Windows execution-recording framework that logs user-mode instructions and process state to `.run` trace files for replay in WinDbg. Its analysis mapped the roles of `ttdrecord.dll`, `TTDInject.exe`, `TTDRecordCPU.dll`, undocumented Windows instrumentation callbacks, and the `ProcLaunchMon.sys` driver in injecting and recording target processes. Researchers found that TTD can trace processes without activating conventional anti-debugging checks and that its signed `CreateDump.exe` component can be used to dump process memory. A concealed `PplDebuggingToken` option can permit access to Protected Process Light targets, including LSASS, but requires a valid Microsoft-signed, device-bound supplemental Code Integrity policy and is therefore not a practical general-purpose PPL bypass. Defenders can monitor or block TTD components and associated trace activity to reduce abuse risk.
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