You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
@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.
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.
The text was updated successfully, but these errors were encountered: