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
Describe The Problem To Be Solved
Smart-lockout is the biggest issue faced when password spraying Microsoft services. While a general assumption on my part, I assume that this security control is based less on source IP and more on the frequency of failed login attempts for a tenant.
Currently, Spray365 exits entirely after a lockout threshold is met which does not work well for long running password sprays as the job must be manually started again to continue.
Suggested Solution
To fix this issue, Spray365 should provide the option to pause for an elongated period of time before continuing with the password spray. For example, if the specified lockout threshold is met, pause execution for two hours before continuing again.
Even more ideally, allow this pause time frame to dynamically increase every time the original lockout threshold is met. For example, the following spray workflow could occur:
A lockout threshold of 10 is set on initial execution along with a pause spray time period of two hours
A password spray is started and after approximately 100 attempts, the lockout threshold is met
The utility pauses the password spray for two hours as specified
After the time frame has elapsed the spray is started
Again after another 200 attempts, the lockout threshold is met and the tool pauses for four hours now instead of two
After the threshold is met X number of times and the paused execution time frame is expanded Y times, the password spray exits
Ideally, this dynamically expanding pause execution timeframe and the condition used to determine if the tool should exit, could also be added as command line options on run.
While the code in Spray365 is very well written, getting a handle on where I would implement this functionality is proving difficult. Let me know your thoughts on this and if I can provide any assistance. Thanks!
The text was updated successfully, but these errors were encountered:
I think enhancing the lockout options is a good idea. I will give this some thought as how to best implement these extended lockout options. In hopes of being helpful, here are some initial thoughts:
Perhaps the simplest approach would be to add a few more parameters (and custom parameter verification logic) to the "spray" module.
Authentication using the current "Credential" occurs here, so I imagine the custom lockout processing would occur somewhere in here.
Please feel free to take a swing at this, as it might be awhile until I get around to adding this enhancement. If you run into any issues or have any questions, let's continue the discussion here.
Describe The Problem To Be Solved
Smart-lockout is the biggest issue faced when password spraying Microsoft services. While a general assumption on my part, I assume that this security control is based less on source IP and more on the frequency of failed login attempts for a tenant.
Currently, Spray365 exits entirely after a lockout threshold is met which does not work well for long running password sprays as the job must be manually started again to continue.
Suggested Solution
To fix this issue, Spray365 should provide the option to pause for an elongated period of time before continuing with the password spray. For example, if the specified lockout threshold is met, pause execution for two hours before continuing again.
Even more ideally, allow this pause time frame to dynamically increase every time the original lockout threshold is met. For example, the following spray workflow could occur:
Ideally, this dynamically expanding pause execution timeframe and the condition used to determine if the tool should exit, could also be added as command line options on run.
While the code in Spray365 is very well written, getting a handle on where I would implement this functionality is proving difficult. Let me know your thoughts on this and if I can provide any assistance. Thanks!
The text was updated successfully, but these errors were encountered: