-
Notifications
You must be signed in to change notification settings - Fork 172
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
False Reporting of Locked Accounts #1
Comments
Yep. It's throttling on Microsoft's end. Been working on a new tool with a different end point and I get the same results. Need to put a wait time of about 5 seconds between requests and also rotate through some proxies for each request. Microsoft is getting wise to this stuff and it's turning into a cat and mouse game. |
Im in the same boat, hoping to have a solution for this soon! |
Solution is to use multiple proxies and an increased wait time. 6 proxies with a wait time of ~10 seconds between each request should do the trick (each proxy makes a request every 60 seconds). I wrote another tool that uses a different endpoint and provides proxy options, but I don't want to step on any toes and post a link. We've used MSOLSpray heavily in the past and it's bad ass. |
Just submitted a PR that (among other things) adds a delay option to the Param block. From my (limited) testing if you add a high enough delay between requests you won't get throttled. |
Has anyone encountered issues where the script was reporting accounts as being locked out when that wasn't the case? I've been getting 10+ accounts reporting as locked out on the very first password spray. Maybe it's a coincidence, maybe the users were almost already at the lockout threshold, but I'm pretty sure it's flagging accounts as being locked out when they're not.
The text was updated successfully, but these errors were encountered: