Windows Internals: SkipThreadAttach

In this post i will not present any new tricks but i will instead discuss a new issue introduced in later versions of Windows regarding thread creation.
In a previous post, i quickly explained the ntdll "NtCreateThreadEx" function and its flag HideFromDebugger 0x4 that when passed to the function causes the new thread to be created hidden from debuggers.

In this post we will see another interesting flag that i prefer to call it SuppressDllMains 0x2. Let's see this in disassembly.

As we can see in the image above, the "PspAllocateThread" function inspects the "Flags" parameter. If the SuppressDllMains 0x2 flag is set, then the function sets the "SkipThreadAttach 0x8" bit flag in the new thread's TEB.

Similarly for the 64-bit version of the function. If the "SuppressDllMains" flag is passed, then the "SkipThreadAttach 0x8" bit flag is set in both the 32-bit TEB and 64-bit TEB of the new thread.

N.B. The bit flags are at offset 0xFCA in 32-bit TEB's and at offset 0x17EE in 64-bit TEB's.

Now let's see what the "SkipThreadAttach" bit flag does. To track this, we will have to shift to user-mode.

In OllyDbg, search for the "\xCA\x0F" (0xFCA) in ntdll.dll and see which functions make use of the "SkipThreadAttach 0x8" bit flag.

The ntdll "RtlIsCurrentThreadAttachExempt" function was among the results i found.

This function returns false if the "SkipThreadAttach" bit flag is not set.
If the "SkipThreadAttach" bit flag is set, another bit flag "RanProcessInit 0x20" is tested. If not set, the function returns true. Otherwise, the function returns false. In C code it looks something like below.

Searching for all references to the "RtlIsCurrentThreadAttachExempt" function, i found one interesting place in ntdll.dll where this function is called, that is LdrpInitializeThread. 

The "LdrpInitializeThread" function is for calling the DllMain's of loaded dlls ( and TLS callbacks as well) each time a thread is initializing (with the "fdwReason" parameter set to DLL_THREAD_ATTACH) or is exiting (with the "fdwReason" parameter set to DLL_THREAD_DETACH).

Taking the "LdrpInitializeThread" function in disassembly, we can see that if  the ntdll "RtlIsCurrentThreadAttachExempt" function returns true e.g. due to the "NtCreateThreadEx" function being called with the "Flags" parameter set to SuppressDllMains 0x2, the DllMains and TLS callbacks of loaded modules will not be called in the context of the new thread. See image below.

A good example for this is the "DbgUiIssueRemoteBreakin" function in ntdll.dll of Windows 7. This function is called by the "DebugActiveProcess" function to create the attaching thread in the context of the process to be debugged.
In Windows XP, the thread created by the "DbgUiIssueRemoteBreakin" function caused the DllMains and TLS callbacks of loaded modules to be called, presenting another layer of protection against attaching.
In Windows 7, since the "DbgUiIssueRemoteBreakin" function ends up calling the "NtCreateThreadEx" function with the "Flags" parameter set to 0x2 (SuppressDllMains), no DllMain's or TLS callbacks are called for the debugger thread.

You can download the demo of this post from here and source code from here.

You can follow me on Twitter @waleedassar

Any comments or ideas are very welcome.

Debuggers Anti-Attaching Techniques - Part 1

It's been a while since i played with packing/unpacking tricks. So, i am going to choose some fancy tricks and try to explain them in detail.

The story begins when i was trying to analyze a security issue in an infamous application. I tried to attach ollydbg to the running process but the process immediately crashed. I quickly googled "anti-attach tricks" and found many useful links.

In the next few posts, i am going to explain those anti-attach tricks.

It would surely be better to understand how debuggers attach themselves to running processes in order to understand those tricks and perhaps innovate new ones.

The main idea behind attaching is that a debugger calls the "DebugActiveProcess" function which ends up with calling the "RtlCreateUserThread" function to create a new remote thread into the target process, with the "DbgUiRemoteBreakin" function as the new thread entry point.

Thread creation occurs in the "DbgUiIssueRemoteBreakin" function, which looks something like the highlighted line in the image below.

As far as i see, one way to prevent debuggers from attaching to a process is conducted by hooking the "DbgBreakUiRemoteBreakin" or "DbgBreakPoint" function.

  I will write a simple executable to demonstrate that. It overwrites the first six bytes of the "DbgUiRemoteBreakin" function with some instructions to jump to the "ExitProcess" function. Similarly, we can patch the "DbgBreakPoint" function.

Here you can download the source code for the example above.

Trying to attach to such a process, as you can see in the image below, results into terminating the process.

Bypassing this trick is pretty easy. Just load olly into another instance of olly, set a breakpoint on the "RtlCreateUserThread" function call, and finally modify its seventh paramter to point to any int3 in the target process address space. 

Once execution stops at int3 (in the debugged ollydbg), kill the current thread.

This way we can bypass this anti-attach trick whether the "DbgUiRemoteBreakin" or "DbgBreakPoint" function is patched in the target process address space.

This bypass trick seems to be impractical. So, i decided to write a simple ollydbg plugin for this situation. The plugin simply patches the "DbgUiIssueRemoteBreakin" function in ollydbg.exe to jump to the plugin code. The plugin code gets the process handle from the stack, allocates memory into this process, and finally writes a few instruction to the new memory.

Here you can download the plugin dll.

N.B. This write-up is based on analysis conducted on Windows XP SP3 and WOW64, windows 7.

N.B. The plugin is tested on windows XP SP3 and WOW64, Windows 7. 

You can follow me on Twitter @waleedassar