I spend a lot of my time debugging LSASS or Winlogon due to what I specialize in ( Active Directory \ Security \ PKI \ GPO’s )
As of XP and greater I have historically done a kernel debug to get at LSASS. If you try to debug it from usermode on the machine you are debugging, you may end up killing LSASS and the machine will reboot due to LSA dying. You are also limited in what you can do ( since the action may require LSASS, and you are debugging it – chicken \ egg thing )
Debugging LSA from Kernel
A kernel debug also gives me the advantage of debugging any other process on the machine. LSA ends up processing a lot of requests from other processes via LPC calls. So, many time, it is very nice to be able to set breaks in these other processes.
When doing a kernel debug with LSA I like to use something like this:
Get the process address for LSASS
0: kd> !process 0 0 lsass.exe
PROCESS 815196c0 SessionId: 0 Cid: 010c Peb: 7ffdf000 ParentCid: 00e4
DirBase: 042d2000 ObjectTable: 81519aa8 TableSize: 859.
Switch to the process context:
.process /p /r 815196c0
.process –i 815196c0 ;g;.reload /user
Debugging CSRSS via setting gflags and NTSD, then piping that info through kernel;
This method will also give you access to all processes on the machine via the | command to switch between them.
So, I can look at LSA, or winlogon, or whatever using this method.
The basic setup is to set gflags for FLG_ENABLE_CSRDEBUG and under the execute option – specify NTSD.exe with the –d switch so the output is sent to a kernel debugger.
Note that your symbols must reside on the target machine in order to access them during the debug.
More info here
Systemwide registry entry, kernel mode.
Runs the Client Server Run-time Subsystem (Csrss.exe) in the Windows Symbolic Debugger (Ntsd.exe) with the following parameters:
-d Send output to kernel debugger console.
-p 1 Attach the debugger to already running Csrss process, as identified by its process ID, 1.
This flag is effective only when the Debug Initial Command (dic) or Debug Winlogon (dwl) flag is also set.
I used to use this one quite a bit – but not so much anymore. There are some risks doing this and plenty of pre-setup work which needs to be done to avoid ending up in a BSOD.
Debugging LSA via dbgsrv.exe
This is my latest best friend ( thanks to a colleague of mine on the base Dev Support team ) .. easy to use and not all the setup of a kernel or csrss debug. You don’t have the risks of debugging LSA on the same machine, nor do you need to reboot to use this method.
When using this method you don’t need symbols on the target either – another bonus.
On the target machine:
Find the PID for LSA via tlist.exe
Then run this command:
C:\Program Files\Debugging Tools for Windows>dbgsrv.exe -t tcp:port=1234,password=spat
On your debugger:
Run this command to attach to LSA on the remote machine.
I:\debugger>windbg.exe -premote tcp:server=192.168.1.102,port=1234,password=spat -p 596 -- where 596 = PID of LSASS
Set your symbols on your debugger:
Symbol search path is: SRV*i:\symbols_pub*http://msdl.microsoft.com/download/symbols
Note that anything which needs LSASS on the target machine, will be postponed while you debug LSA ( until you ‘g’ the debugger )
Now you are ready to go!
When you want to quit – make sure you use ‘qd’ to ‘quit and detach’ so you don’t kill LSA on the target machine.
Have fun debugging...
PingBack from http://collegefunfactsblog.info/spats-weblog-steve-patrick-debugging-lsass-oh-what-fun-it-is/
PingBack from http://huaidan.org/archives/2012.html
去问比尔大叔吧。 先不管是不是真的有，我们可以自己实现一个这样的后门。 先简单介绍一���windows登陆过程中...