Windows XP expert's help needed...

Hi,

as some of you might know i have written a program which can dump the password from the current user to the screen in windows XP and windows 2003.

Well i'm trying to add XP SP2 support to it, but i'm having a hard time understanding windows...

here's the deal:

when i log in to my computer and i search the memory in winlogon.exe or lsass.exe for my password i won't find it, but as soon as i have changed my password in the same session, i CAN find the password in the memory of winlogon.exe . now at this point the password most of the times is in exactly the same place, but i need to figure out a way to find that password even without having to change it first.

so if anyone can give me a good reason WHY there is a difference between changing or not changing your password, that would be really great since then i can continue (and perhaps finish) my research for this program and add SP2 support to it.


Many thanks in advance,

Kind regards

IIRC, one of the better features of SP2 was the new code it enforced when handling memory and buffers. It would "Secure" used memory so that it couldn't be tampered with while in use (for at least the Windows OS core files like you mentioned) as well as keep it in checks so it couldn't be overran with buffer overflows.

Just a hunch, but that may be why you can't read the current information on a typical Windows session. The information in that file may be secured in RAM, but once the password is changed the program basically had to circumvent SP2's protection on memory to change the password for the entire system.

That would be a flaw in the SP2 security memory measures, but nessessary for the password change to take immediate effect.

Of course, all of this is merely acedemic and I could be way off.

i think you might be right, but i need to know for sure...

personally i think M$ has developed a new way of storing the password and implemented this in SP2 for XP and SP1 for 2003, since the password is stored different then in the past (windows 2000, XP up to SP2 and 2003 SP0).

do you happen to know of any place where i could find info that goes this deep into the OS?

Quote:

---

The best way to get passwords for windows XP, is to put
Cain & Abel V2.5
on a CD, Goto the computer you want the password for, boot it up in safemode... press F8 a bagillion times on start-up and it will give you the Safe-mode option..... and a new user will appear called Adminastrator..... log into it, it has no password, unless someone already fixed that method... wich is very rare, once it creates all the files and logs you on,
BOOM
, open cain, install it and it will will RIP the LSA secrets right outta the comp.... :P Use only if you lock yourself out by accident....or something....

---

sorry, but this is not what i am after.
i'm trying to figure out a way to READ the password without having to crack it first.

one disadvantage of your method is that if the user uses a strong password, it will take a long time cracking it. this might become days, weeks, months or even years...

so thanks for your reply, but i am afraid it will not help me :(

[edit]altered the post, since i was a bit to hard on the poster[/edit]

it took it a matter of seconds to crack 'forgottenuranium6991147' <---- old XP pass... :P
sorry the post waz off SUB. :P

A strong password does not mean length alone. The ethics of a strong password include such things as using upper and lower case letters, special characters, password length, using a passphrase instead of just a singular word.

A sturdy example of a proper password might be:

@nd_Th3_W0rlD_FeLl_StilL_@

Just be sure to remember it.

Quote:

---

it took it a matter of seconds to crack 'forgottenuranium6991147' <---- old XP pass... :P
sorry the post waz off SUB. :P

---

, i must have misread your post, i was under the impression that you used cain to crack the password hashes, but you are using it to dump the lsasecrets.
this method is highly unreliable since it will dump the default password, if you have multiple users on the system it might display the password from another user (the one which is default).

also it won't work with SP2 appearantly since i just ran cain, and no password was displayed...

cain uses the same approach as lsadump2, this programs gives the same output, except you wont need to install it, just run it from the command line.

also be careful with lsadump2 and XP Sp2, the version i have crashes lsass.exe which results in a forced shutdown of the system...

You need to inject a .dll into the Winlogon process to capture the logons when they happen. JeFFOsZ has written a tool using this method. PM me if interested,


-Maestr0

I have found a way to kill the 60 second shutdown sequence thingy... goto command prompt or RUN which ever is the closest and type shutdown -a and it aborts the shutdown... WITH the lsass.exe crashed... from there you can restart the lsass, sometimes you can bring the system back up, and sometimes you cant... depends on how bad the situation is i guess? But cain also has a bruteforcer.... not just lsa secrest dumper.... and Cain has recently issued a new release 2.5 FULL, they have like 20 diff 2.5's but only their last update will work right, even with SP2 i think... :P

Binary, your method seems a bit too sloppy for any job, to be honest. Crashing the computer, reloading lsass, hoping it actually works, and then brute forcing a password is just too much mess and trouble for it to be effective in a real world situation. Not only would the Event Log show a list of service crashes and when you restarted lsass, but brute force itself can take time. Especially if someone used a password similar to the technique I mentioned earlier in this thread.

Windows XP doesn't store their passwords in a simple blowfish or HTML-based encryption method. It's a decently secure hash level of encryption, and because the brute-forcer has to check hash against hash instead of letter to letter (e.g. aaaaaa to zzzzzz) the amount of time required is much longer.

Maestr0's method seems to do the job much faster. An injection would prove to be the less noticible while remaining just as effective. Of course, to be perfectly honest, if everyone is going to try shutdown -a or file injection then it sounds like they already have admin access or at least local machine access.

At that point in time, fsck the messy methods and just install a hardware keylogger onto the keyboard.

Maestr0 --> i'm surely interested, although i do not believe it is the ONLY way...

Quote:

---

At that point in time, fsck the messy methods and just install a hardware keylogger onto the keyboard.

---

the main goal isn't retrieving someone elses password, the main goal is retrieving it from memory. you can use such a program for penetration tests, and a hardware keylogger shouldn't be used for pen-testing since it wouldn't be completely fair. it's the same as putting a camera on the keyboard to see what the user types... this should be able to do remotely, and installing a hw keylogger is a hard job doing remotely ;)

I agree with you, white.

The point I was leaning moreso torwards, I guess, is that if they are running "shutdown -a" to save the lsass.exe shutdown.. or injecting a file library protected by the administrator account, then chances are they already have administration access or local access to the machine. This is because the first process requires you having local access (or real time VNC access remotely) with administrative privleges.

The second method of injecting could be done remotely by virus usage or getting a dumb employee to run a precompiled program to preform the injection. But then what? Due to SP2 the windows system files, once loaded in memory, are unable to be modified. Most of their memory registers are also already encrypted on the spot. The only way to overwrite a windows protected system file (exe or dll based, mostly) is by rebooting the computer into Safe Mode and proceeding that way due to the i386 folder kept within the primary Windows folder, which dissallows and immediatally replaces any windows system files that have been modified. Thus, again local access or even remote VNS administrative access would be required.

So, there you have it :) I agree that the point isn't to use something so obvious, but the methods described so far either already require administrative access (and thus already able to control the system and user's passwords) or local access (and thus open up billions of ways to gain passwords from the hard disk).

Of course, this is all academic, and I may have missed something on the whitepaper of SP2 secure file handling.

Quote:

---

The second method of injecting could be done remotely by virus usage or getting a dumb employee to run a precompiled program to preform the injection. But then what? Due to SP2 the windows system files, once loaded in memory, are unable to be modified. Most of their memory registers are also already encrypted on the spot. The only way to overwrite a windows protected system file (exe or dll based, mostly) is by rebooting the computer into Safe Mode and proceeding that way

---

It is possible to disable the WFP on the fly by closing the Handles that are monitored by WFP. Also the process which monitors WFP directories is actually our very same winlogon.exe. :) so I would not rely on WFP to save you, and I dont believe code execution vulnerabilities in Windows are particulalry rare. :)

-Maestr0

Good point. I didn't think WFP was so easily exploitable remotely.

How would one defeat WFP ('windows file protection' for those who don't know) remotely?