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.