Skip to content
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

Breaking Issue - Accounts not being reported as Locked when they get locked. #3

Open
ZerkerEOD opened this issue Nov 2, 2023 · 2 comments

Comments

@ZerkerEOD
Copy link

I have been running this for a while and there appears to be an issue that just popped up on one of my internal engagements. I used ldap relaying to get a list of all user accounts, then used the enumeration feature of Talon to look for valid and non valid accounts to test against. Once I got a list of valid accounts that were not locked (I found it odd they had no disabled accounts), I started my password spray and this morning the client said they had over 500 accounts locked in a 10 minute period. They confirmed that they were doing a lockout of three failed attempts in 30 minutes, I ran my test with 2 in 35 minutes. During my test it appears that 536 of 571 accounts I was spraying were locked in the first 10 minutes. Something tells me that 536 of their users did not enter a password wrong in the first 10 minutes of my scan.

The concerning part is that through the testing, only three accounts were reported back to Talon as being locked. All others were reported as a failed login attempt.

@ZerkerEOD
Copy link
Author

After doing some additional research, we think their domain was acting weird, and we are waiting for more information to confirm. We are looking to see if their domain was seeing the enumeration part of it as a failed attempt for some reason. Will post back when I have more information.

@ZerkerEOD
Copy link
Author

@Tylous, I have confirmed that through testing, the userenum function will lock user accounts and will create a failed login attempt. Looks like the Cipher that is being used is not disabled by default on Windows Server 2022 and if not configured currently to have 3DES disabled, it will create a failed attempt using null authentication.

The following screenshot shows me using a test account added three times in the file (should have just done four but it was an after thought) then running it once on a domain with the password policy set to lock accounts after three failed attempts, then me running it again to find that the account was locked.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant