Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Windows AD account's erroneous passwords are cached #51

Open
carmaa opened this Issue May 2, 2012 · 12 comments

Comments

Projects
None yet
5 participants
Owner

carmaa commented May 2, 2012

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.

init99 commented May 3, 2012

Pull network cable on target. Normal Windows PW checking is AD then local cache. Bypassing AD will allow tool in current state to work.

Owner

carmaa commented May 3, 2012

Have you tested this?

init99 commented May 3, 2012

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.

Owner

carmaa commented May 3, 2012

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).

Owner

carmaa commented Oct 7, 2012

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.

Owner

carmaa commented Oct 11, 2012

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.

@carmaa carmaa closed this Oct 11, 2012

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?

Owner

carmaa commented Jan 7, 2014

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.

@carmaa carmaa reopened this Jan 7, 2014

Owner

carmaa commented Jan 7, 2014

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?

@ghost ghost assigned carmaa Jan 7, 2014

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment