Analyzing TLS Callbacks

analyze malware tls callbacks
Ever lost control of a program before the debugger could pause? TLS Callbacks may be old news, but they remain a viable tool still utilized by malware for anti-debugging and other trickery.


TLS (Thread Local Storage) callbacks are stored in the PE header and provided by the Windows operating system to support additional initialization and to terminate per-thread data structures.

TLS callback functions can be manually programmed into a binary where the original intent is to initialize and clear TLS data objects. However, like all relatively unknown and quirky Microsoft-isms malware found a way to abuse them.

Enter Player 3

The great part of TLS callbacks is that Windows executes these functions before executing code at the traditional start of the program. Back in the day debuggers would typically break at the main function or the Original Entry Point (OEP) of the program.

However, if a TLS callback is used in the binary its code will run before main is executed. This is why malware often utilizes TLS callbacks for out-of-scope debugger detection for anti-analysis, polymorphic manipulation of the binary after execution, unpacking routines, or simply for obfuscation.

Catching TLS

Over time debuggers slowly started to include options to catch these TLS callback routines either by breaking on them directly or at the system entry.

While TLS callbacks may not be as tricky as they once were they are still being used to this day by all families of malware and it is a good idea to keep them in mind when analyzing Windows binaries.