-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows AD account's erroneous passwords are cached #51
Comments
Pull network cable on target. Normal Windows PW checking is AD then local cache. Bypassing AD will allow tool in current state to work. |
Have you tested this? |
Yes. Successfully patched an XPsp3 workstation on domain. Attempt to log in fails. Remove network cable, try again, success. However, if network cable is reconnected, any attempts to access network resources seem to use the "fake" password and will fail. |
Ah, OK so what you are saying is that the patch won't work if the computer is connected to the domain. That's expected. The issue is more related to the fact that windows cache the erroneous password (like you mentioned) and that subsequent AD authentications will fail. That being said, I'll look into if there's a way to patch the method that decides if a password is needed at all (I think winlockpwn did this). |
Adding signatures for all Windows systems patching the call that decides if the account needs to enter a password to authenticate or not - should take care of this issue. |
Further investigation shows that patching will work both in "Not logged in" (with network cable unplugged) and "Locked" states. Laptops will likely be on WiFi which one may or may not be able to turn off with hardware switches. As the tool is intended for Locked machines, this issue is closed for now. Would need a secondary patch for all Windows patches to ensure that the hash resulting from the authentication is not cached. |
Just wanted to ask prior locking my domain account again as I did in the past - is the caching of incorrect credentials already sorted out or an unlock on a computer joined in a domain will result in a locked account as it did before? |
Yeah... That's still a problem, unfortunately. Considering re-reverse engineer new sigs for Windows 7 and up for the next big release. Let's reopen this ticket to remind myself. |
By the way and completely off topic - any idea why I suddenly have 60 new people starring this project over a timespan of 2 days? |
No idea at all. Personally I was about to ask my question on http://www.breaknenter.org as I did 2 years ago here - http://www.breaknenter.org/projects/inception/#comment-1550, when I recalled that there is already an open ticket on Github for it. :-) Perhaps the repo was mentioned on some popular place? |
Any updates on this issue? |
Why not put the "old"/correct hash back in it's place after it's unlocked? You should be able to copy/save/print to screen, and then copy it back no? |
Since Windows cache passwords, the password entered after use of the tool is used against AD, locking the AD account out of the domain. Need to investigate alternative patching methods.
The text was updated successfully, but these errors were encountered: