Skip to content
New issue

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

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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)
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant