I've never seen TLS data be "run" first, however, in the case of a non dynamically loaded PE, the .tls section is loaded before the entry point is run. TLS slots are also initialized by the loader before then entry point is called. TLS and FLS can both be used by malware to create in memory storage that is slightly harder to inspect during run time.
If you know that malware is reading/writing TLS/FLS, you could presumably put a hardware breakpoint on the memory being used for the TLS/FLS. When the malware reads/writes that memory, the debugger should break, and you'll be able to inspect the process state while the debugger is broken. I guess this could be useful if the malware was heavily obfuscated and it was difficult to trace the control flow of the malware.
Furthermore, if the malware is storing executable code in the TLS sections, you could write an 0x3C (int3) into the first byte of the code, which would cause the debugger to break if/when the code was executed.
TLS is typically used in one of two ways. First, is to use the tls functions (TlsAlloc, TlsSetValue, TlsGetValue, TlsFree etc). The second would be to define thread local variables with __declspec(thread)
, which would add a .tls section with the initialized value to the compiled PE file (which should be an exe, not a dll if you are using __declspec(thread)
). FLS is only available via the Fls* functions, there is no __declspec(fiber)
to my knowledge.
There is nothing inherently malicious about TLS or FLS, but they are used by some forms of malware in an attempt to hide data from analysis.