Account Lockout Considerations

[KyanHexagon]

I would suggest implementing some features to account for account lockouts. For example if I feed http.ntlm2 module a list of usernames and a list of passwords have it spray the first password against all usernames and then have a flag where I can set how long to wait before spraying the next password and all usernames.

Also, I was wondering if the output flag only outputs successful attempts? It would be useful to have a record of all of the username/password combinations tried in a file.

[evilsocket]

Did you check the --rate-limit, --jitter-min and --jitter-max options?

[KyanHexagon]

The wiki says that when a list of usernames and a list of passwords are provided legba will load both from wordlists and use all combinations. Does it try one password against all users and then move to the next password? If it does, I can see how I could use those flags to slow down and spread out the requests in order to ensure a certain amount of time passes before it starts with the next password spray.

I was thinking more along the lines of the Spraycharles flags --attempts (Number of login submissions per interval for each user) and --interval (Minutes between login intervals). https://github.com/Tw1sm/spraycharles

[evilsocket]

no it will try every password for each user and then move to the next user:

for user in users {
  for pass in passwords {
     rate_limit_if_needed()

     login_attempt(user, pass)
  }
}

[KyanHexagon]

Okay, so say I wanted to only do one password spray an hour to try and prevent account lockout. Using the --rate-limit, --jitter-min and --jitter-max options with the current way lists are iterated wouldn't be helpful. I would need to set the rate limit to an hour and it would have tried only a single user:password combo.

If instead a single password was tried against all usernames before trying the next password I could do (Lockout Interval in seconds)/(Number of Users)=(Rate Limit) to find the rate limit to use to ensure only a single password attempt is performed on each user during my desired lockout interval before it starts the next password spray.

[evilsocket]

i see, sounds like it'd be useful to have an option which determines how to iterate basically

[D3vil0p3r]

Is it like hydra -c argument right? It could be useful to test account timeout/lockout security mechanisms

hydra -h
<SNIP>
-c TIME   wait time per login attempt over all threads (enforces -t 1)
<SNIP>

[evilsocket]

In Legba's case i'm thinking to add an argument which determines the iteration logic so that the --rate-limit parameter can be used in different contextes.

Legba's equivalent of Hydra's -c is --rate-limit

[evilsocket]

Something like (just a draft idea):

--iterate-by user (default mode):

for user in users {
  for pass in passwords {
     rate_limit_if_needed()

     login_attempt(user, pass)
  }
}

--iterate-by password

for pass in passwords {
  for user in users {
     rate_limit_if_needed()

     login_attempt(user, pass)
  }
}

[D3vil0p3r]

--rate-limit is not clear for me as described, sorry. On legba wiki is reported:

--rate-limit	0	Limit the number of requests per second.

Assuming that the input value is an integer, by --rate-limit the user can only set the number of requests per second, so, at minimum it can send 1 request at 1 second.

What hydra -c does is to not set the number of requests to send but how many seconds I must wait per request, that is different according to the --rate-limit description, unless there is a way to reach the same purpose by mixing --rate-limit with another argument, or if the input value of --rate-limit is a floating point value.

Summarizing, hydra -c allows me to set the number of seconds to wait per request, --rate-limit allows me to set the number of requests to send per second.

Please, tell me if I'm wrong. Thanks.

[evilsocket]

@D3vil0p3r you are not wrong, but even implementing an equivalent of hydra's -c wouldn't solve the problem that @KyanHexagon mentioned due to the iteration logic ... so I'll probably need to implement both :)

[evilsocket]

Implemented both features, so to summarize:

default behaviour (loop by username, no rate limiting or waiting):

for user in users {
  for pass in passwords {
     login_attempt(user, pass)
  }
}

--iterate-by password -> inverts the loop nesting, no rate limiting or waiting

for pass in passwords {
  for user in users {
     login_attempt(user, pass)
  }
}

--iterate-by password --rate-limit 1 -> inverts the loop nesting, one attempt per second (fixed wait time of 1 second)

for pass in passwords {
  for user in users {
     login_attempt(user, pass)
     sleep(1s)
  }
}

--iterate-by password --wait 200 -> inverts the loop nesting, wait for 200ms after each attempt

for pass in passwords {
  for user in users {
     login_attempt(user, pass)
     sleep(200ms)
  }
}

And so on with all combinations. I think that this approach offers any rate limiting and iterating logic one desires :)