[Web] Brute Forcer v1.1[Web] Brute Forcer v1.1
[ Opportunities ]
[+] Brutal method POST
[+] Brut method GET
[+] Brutal Basic Authorization ( HEAD Method)
[+] Brutus FTP
[+] Multithreading (1 ~ 1000 threads)
[+] Ability to set additional Request (GET / POST) variables.
[+] The ability to set cookies.
[+] Brutus using a proxy (built-in proxy rotator with avtochek function and custom auto-change)
[+] 3 attack modes:
- Attack 1 login
- Attack multiple logins
- Attack on 1 password
[+] Built-in plain HTML browser with highlighting of input tags and displaying headers received from the site.
[+] Dictionary Manager (Generation, gluing, breakdown)
- The program requires .NET Framework> 2.0
- Settings are stored in the Config.xml file
- Saved items from ComboBox can be deleted by pressing Ctrl + Delete.
- When started with the / oldstyle switch, the program will have the old style.
- When changing the tab, the GUI slows down a bit.
- Try not to use Cyrillic characters in the indicator (as some sites send the wrong encoding in the header). - The program is still raw, so I hope for your advice / glitches found.
[Manual for beginners]
It is necessary to transfer the web form data to the program.
To do this, open the Sorts page and find the <form> tag (there may be several of these tags, so you need to make sure that this is the right form.).
1. In this <form> tag, look for the action attribute. This is the target URL . If there is no such attribute, copy the URL of the page from which we opened the page. There is also a method attribute. If it is POST , then set the Protocol / Attack Method to HTTP-POST , if GET is HTTP-GET . (Note that all transitions using the GET method are saved in server logs, so the fact of brut is most likely quickly recognized by the growing size of the logs.)
2. Then inside our <form> tag we look for <input> tags (there is a backlight in the Browser). These are the so-called fields. We need to get the fields of identifiers, that is, the fields in which the login and password are transmitted when sent to the server.
We are looking for the name attribute in the <input> tag. If its contents are similar to login , nickname , username, and so on. (I think the essence is understood), this is the login field. Copy the name attribute in the " Login" field " " of our program.
We do the same with the "password" field (it will probably be named pass , password , pwd , etc.).
You also need to transfer additional fields ( name and value attributes) to the Additional request-variables section.
If inside the <form> tag there is a <input> with type = "submit" , then this is the login button. We transfer its attributes to the program in the section " Attributes of the Submit-button ".
If any <input> tag does not have a name attribute, then it does not interest us.
3. Then you need to set a text indicator of a successful login .
This is an important parameter and is different for each site. According to this indicator, the program will decide whether a successful entry occurred or not. That is, if the specified text is absent / present in the source of the page, then the login is considered successful.
As an indicator, you can use a form code fragment (since it will certainly be absent from the page if a successful attempt is made), or, if you have an account on the attacked site, use a code fragment that is uniquely present on the page upon a successful attempt (for example, the code of the Exit button). " from the website).
4. Then, if necessary, set cookies . What is it - we read in Wikipedia. Copy them from the browser to the program.
For fidelity, you must first completely clear the cookies of the attacked site, then go to it, and only then copy. Cookies are usually checked by the website to ensure that you are not a robot.
5. As for the type of search , I think everything is clear.
If you need to pick up 1 account, enter the login and specify the file with passwords .
If there are several accounts , you need a file in which the login and password are separated by a separator , for example:
With an attack on 1 password, I think you will figure it out for yourself.
If you have a working account on the attacked site, do not be lazy - be sure to test the program on it.
A clear indication that the program is configured incorrectly is the situation when all attempts are correct (the results are shown in the program log field). If this happens, recheck the parameters.
[Configuration example for mail.ru brut]
As the saying goes, "skis do not go skiing, I ....
Ps. in cookies, variables obtained automatically when visiting mail.ru. As I found out, the values of these fields can be any, since when a login is checked for their existence, and not the contents.
[Web] Brute Forcer v1.1
webbruteforcer.zip [50 kb]