Nunca he visto "ejecutar" datos TLS primero, sin embargo, en el caso de un PE no cargado dinámicamente, la sección .tls se carga antes de que se ejecute el punto de entrada. Las ranuras TLS también son inicializadas por el cargador antes de que se llame al punto de entrada. El malware puede usar TLS y FLS para crear en el almacenamiento de memoria que es un poco más difícil de inspeccionar durante el tiempo de ejecución.
Si sabe que el malware está leyendo / escribiendo TLS / FLS, probablemente podría poner un punto de interrupción de hardware en la memoria que se está utilizando para el TLS / FLS. Cuando el malware lee / escribe esa memoria, el depurador debería interrumpirse, y podrá inspeccionar el estado del proceso mientras el depurador está roto. Supongo que esto podría ser útil si el malware estaba muy confuso y era difícil rastrear el flujo de control del malware.
Además, si el malware está almacenando código ejecutable en las secciones TLS, podría escribir un 0x3C (int3) en el primer byte del código, lo que causaría que el depurador se rompa si / cuando se ejecutó el código.
TLS se usa normalmente de una de dos maneras. Primero, es usar las funciones tls (TlsAlloc, TlsSetValue, TlsGetValue, TlsFree, etc.). El segundo sería definir las variables locales de subprocesos con __declspec(thread)
, que agregaría una sección .tls con el valor inicializado al archivo PE compilado (que debería ser un exe, no una dll si está usando __declspec(thread)
). FLS solo está disponible a través de las funciones Fls *, no hay __declspec(fiber)
que yo sepa.
No hay nada intrínsecamente malicioso en TLS o FLS, pero son utilizados por algunas formas de malware en un intento de ocultar los datos del análisis.