Skip to main content

Web App Range

The broadest web target: one app, planted weaknesses across every OWASP-style category.

Run a Cracken operation against a deliberately vulnerable web application and see it discover and confirm a spread of common web weaknesses. This range is a single multi-user web app seeded with planted vulnerabilities across the OWASP-style categories.

Authorized lab range — scope strictly to it

https://77.42.79.6/ is a disposable, isolated lab target provided for testing Cracken, and you are authorized to assess it. Point Cracken only at 77.42.79.6. Running the same operation against any other host — including a production system that happens to share that address elsewhere — is unauthorized testing.

Prerequisites​

  • Access to a realm in your tenant.
  • A connected Tentacle with network reach to 77.42.79.6 on port 443.
  • Optional: the built-in Web App Pentest Playbook (a system playbook available in every realm).

The target​

PropertyValue
URLhttps://77.42.79.6/ (self-signed certificate — expect a TLS warning)
TypeMulti-user web application with login
Example accountsupport / 12345

The app ships with several low-privilege accounts and one admin account so the operation can test both unauthenticated and authenticated surfaces. The full credential list is in the appendix.

Run it in Cracken​

  1. Open or create a realm and confirm a Tentacle is connected.
  2. Create a new operation and select the Web App Pentest Playbook, or describe the goal yourself — for example: "Map https://77.42.79.6/, then check for SQL injection, reflected and stored XSS, CSRF, IDOR, remote code execution, and authentication weaknesses. Confirm each finding."
  3. Set the target to https://77.42.79.6/.
  4. Run the operation. In Manual mode you approve each proposed action; in Semi or Auto mode the agent works through the surface on its own.

A common pattern for this range is to let the agent map the app first, then spawn a sub-operation per vulnerability class so each check runs independently.

What to expect Cracken to find​

The app has planted weaknesses in these categories. A successful run surfaces them as findings, with the linked hosts, endpoints, and credentials captured in the Cybergraph:

  • SQL injection — in the project search, via raw string concatenation in the query.
  • Cross-site scripting — reflected XSS in user search and stored XSS in the messaging feature.
  • CSRF account takeover — the profile-update form has no anti-CSRF token.
  • IDOR — project data is reachable by changing the object id in the URL with no ownership check.
  • Remote code execution — command injection in the admin diagnostic panel.
  • Authentication weaknesses — username enumeration through distinct login error messages, plus weak, reused passwords.

You have a clean PoC when the operation has confirmed at least one finding in each category and the report lists them with evidence.

Next steps​

Appendix: range reference​

Accounts and planted-vulnerability detail (spoilers)

This section is the answer key. Skip it if you want the operation to find everything on its own.

Accounts​

RoleUsernamePassword
Adminadminmonkey
Useraccounting123456
Usermarketingpassword
Usersales12345678
Userhrqwerty
Userwebmaster123456789
Usersupport12345
Usertest1234
Useruser111111
Userjohn1234567
Usermikedragon
Userdragon123123
Userqwertybaseball

Planted vulnerabilities​

  1. SQL injection — blind boolean-based, in the project search. The query concatenates raw input. Probe value: q=test' OR '1'='1.
  2. Cross-site scripting
    • Reflected — employee search echoes unsanitized error messages when searching a non-existent user.
    • Stored — messages are saved and rendered without sanitization, affecting inbox and sent views.
  3. CSRF account takeover — /profile/update has no CSRF token; a hosted form can change the victim's email and password.
  4. IDOR — /api/projects/{id}/details returns any project's data regardless of membership.
  5. Remote code execution — command injection in the admin diagnostic panel runs arbitrary system commands.
  6. Authentication weaknesses — login returns a different message for a non-existent user versus a wrong password, enabling username enumeration; all accounts use weak, common passwords.

These are target-app routes and behaviors, not Cracken routes.