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

Some logic errors in the lockout thresholds handling #19

Open
themaks opened this issue Feb 24, 2020 · 0 comments
Open

Some logic errors in the lockout thresholds handling #19

themaks opened this issue Feb 24, 2020 · 0 comments

Comments

@themaks
Copy link

themaks commented Feb 24, 2020

There seems to be some errors in the handling of account lockout thresholds.

  • First, the variable $SmallestLockoutThreshold is defined as the minimum value of all account lockout threshold (from the domain policy and other fine-grained password policies), as follows :

[int]$SmallestLockoutThreshold = $AccountLockoutThresholds | sort | Select -First 1

For each of these policies, a 0 value means that the lockout policy is disabled. However, if the lockout policy is disabled for a specific perimeter but not all accounts, the "minimum" value computed above is wrong (0), since it is hinted after that this value means no lockout policy for all accounts :

https://github.com/dafthack/DomainPasswordSpray/blob/94cb72506b9e2768196c8b6a4b7af63cebc47d88/DomainPasswordSpray.ps1#L385:L388

  • As a consequence, some accounts are not tested password spraying on a domain where there is no lockout policy (on at least one perimeter). Indeed, the way the $attemptsuntillockout variable is computed does not take the $SmallestLockoutThreshold=0 case into account :
    $attemptsuntillockout = $SmallestLockoutThreshold - $userbadcount

This value will never be greater than 0 (thus than 1), so the second part of the condition tested to add a specific user to the list of targets will never be True :

if (($timedifference -gt $observation_window) -or ($attemptsuntillockout -gt 1))

So, every account with a bad password attempt made in the last $observation_window minutes is skipped.

To solve all these problems, I suggest you add some arbitrary high value in to the $AccountLockoutThresholds list instead of 0 when $objDeDomain.Properties.lockoutthreshold or $PSOLockoutThreshold is equal to 0.
Here :

$AccountLockoutThresholds += $objDeDomain.Properties.lockoutthreshold

And here :
$AccountLockoutThresholds += $PSOLockoutThreshold

mdavis332 added a commit to mdavis332/DomainPasswordSpray that referenced this issue Mar 13, 2020
account lockout threshold of 0 = never lock out; fix logic introduced by sorting by that field. ref dafthack#19 (comment)
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