Hydra https-form-post [closed]

Question

I have never experimented much with online password crackers. I attempted to use Hydra today on this website www.athena2.harker.org and I keep getting false positives.

This is what I have done so far:

• pinged the website and obtained the IP address of 209.23.201.55

• identified the form type, its an https-form-post

  <form id="login" method="post" action="https://athena2.harker.org/login/index.php">
  

• found the failure response: it's “Invalid login, please try again”

• run this command

  hydra 209.23.201.55 https-form-post "/login/index.php:username=^USER^&password=^PASS^&Login=Login:Invalid login" -l test -p test -t 10 -w 30 -o example.txt
  

Can someone tell me what I am doing wrong?

_{I work in IT for the school. We operate on the open source Moodle platform, and a student recently obtained administrator access, we are evaluating the strength of the passwords we issue. (6 digit/lowercase letter password). Don't assume people on this forum attack targets maliciously, penetration testing and computer security are legitimate fields, I thought everyone here would be aware of that.}

Answer 1

You're attacking a live system, that is what you're doing wrong.

Please stop unless you have explicitly been contracted to break security on this service (i.e. You have a signed penetration testing contract with the server owners).

Edit:

It's good that you have permission to perform this test (I've seen a surprising number of similar questions where this isn't the case, and the users would be putting themselves at grave risk of prosecution).

So with the new information, your objective is to test the strength of passwords with 6 lower case letters.

1. You can do this theoretically. The maximum possible permutations are 26^6 = ~309 million. Take your login rate limit per unit time, and you can then figure out how long it would take to crack a password. With a properly configured web app, this method should never work (Assuming your admin passwords are random).

2. You can do this by taking the salted and hashed password file, and brute forcing it "offline". This more accurately simulates what would happen in an attack, and eliminates the risk that attacking the live system would cause a fault.

Answer 2

It is quite common for web servers not to display the same error after about 20 consecutive errors, try looking for the input fields, they tend to be there until a successful login.