🔗Multi-Step Profiles

Multi-step profiles allow you to chain multiple scanning steps together in a sequential flow. This is essential for testing vulnerabilities that require multiple requests, such as multi-stage attacks, authentication-dependent tests, and workflows that rely on state from previous requests.

💡 Concept

A multi-step profile executes a sequence of steps, where each step is a complete scan configuration (payloads, grep patterns, insertion points). Steps are executed sequentially, and cookies/state can be shared between them.

Step 1: Send initial payload → Match response
  │ 🍪 (cookies carried forward)
  ▼
Step 2: Send follow-up payload → Match response
  │ 🍪 (cookies carried forward)
  ▼
Step 3: Send verification payload → Final match → 🐛 Report issue

📊 Step Structure

Each step in the steps[] array contains the same fields as a regular profile, plus additional multi-step-specific fields:

Field	Type	Description
🍪 reuseCookie	Boolean	Carry cookies from the previous step's response
📍 insertionPoint	String	"same" to reuse the matched insertion point from the previous step, or null for all insertion points

All standard profile fields are available per step: Payloads, Grep, MatchType, InsertionPointType, RedirType, MaxRedir, Header, NewHeaders, etc.

⚙️ How Multi-Step Execution Works

1. 1️⃣ Step 1 executes with its payloads and insertion points

2. ✅ If Step 1 matches, the scanner records:

   • 📍 The matching insertion point

   • 🍪 Any cookies set in the response

3. 2️⃣ Step 2 executes using:

   • 🍪 Cookies from Step 1 (if reuseCookie: true)

   • 📍 The same insertion point as Step 1 (if insertionPoint: "same")

   • 🌐 Or all insertion points (if insertionPoint: null)

4. 🔄 This continues for all steps in the sequence

5. 🎯 Stop-on-match: If any step fails to match, the entire sequence stops for that insertion point

🍪 Cookie Reuse

When reuseCookie: true:

1. The response from the previous step is analyzed for Set-Cookie headers

2. All cookies are collected and added to the next step's request

3. This enables testing scenarios like:

   • 🔓 Login → Access protected resource

   • 🛡️ CSRF token retrieval → Use token in attack

   • 🔑 Session setup → Exploit session-dependent vulnerability

📍 Insertion Point Reuse

When insertionPoint: "same":

• The step tests only the same insertion point that matched in the previous step

• This ensures the attack chain targets a consistent parameter across all steps

• If not set (or null), all configured insertion points are tested

📚 Example: Multi-Step Authentication Test

[
  {
    "ProfileName": "Auth_Bypass_MultiStep",
    "Enabled": true,
    "Scanner": 1,
    "Author": "@researcher",
    "steps": [
      {
        "Payloads": ["true,admin"],
        "Grep": ["true,,Simple String,,Set-Cookie: session="],
        "MatchType": 2,
        "InsertionPointType": [1],
        "reuseCookie": false,
        "insertionPoint": null,
        "RedirType": 4,
        "MaxRedir": 3
      },
      {
        "Payloads": ["true,/admin/dashboard"],
        "Grep": ["true,,Simple String,,Welcome, Admin"],
        "MatchType": 1,
        "InsertionPointType": [66],
        "reuseCookie": true,
        "insertionPoint": null,
        "RedirType": 4,
        "MaxRedir": 3
      }
    ],
    "Tags": ["All", "Auth"],
    "IssueName": "Authentication Bypass",
    "IssueSeverity": "High",
    "IssueConfidence": "Firm",
    "IssueDetail": "<br/>- PAYLOAD: <br/><payload>\n<br/><br/>\n- GREP: <br/><grep>"
  }
]

🔄 Flow:

1. 1️⃣ Step 1 sends admin as a body parameter and checks for a session cookie

2. 2️⃣ Step 2 reuses the session cookie and requests /admin/dashboard, checking for admin access

📚 Example: CSRF Token Retrieval + Exploitation

{
  "steps": [
    {
      "Payloads": ["true,GET /form"],
      "Grep": ["true,,Regex,,name=\"csrf_token\" value=\"([^\"]+)\""],
      "MatchType": 2,
      "reuseCookie": false,
      "insertionPoint": null
    },
    {
      "Payloads": ["true,<script>alert(1)</script>"],
      "Grep": ["true,,Simple String,,<script>alert(1)</script>"],
      "MatchType": 1,
      "reuseCookie": true,
      "insertionPoint": "same"
    }
  ]
}

⏱️ Time-Based Detection in Multi-Step

Multi-step profiles support time-based detection through the checkTimeDelayGreps() method. This enables timing attacks where:

1. 1️⃣ Step 1 sends a baseline request (no delay)

2. 2️⃣ Step 2 sends a time-delay payload

3. ⏱️ The time difference is analyzed to confirm the vulnerability

🎯 Stop-on-Match Behavior

Multi-step profiles have built-in stop-on-match logic per step:

• ✅ When a step matches, subsequent payloads for the same step are skipped

• ➡️ The sequence proceeds to the next step

• ❌ If a step fails to match, the entire sequence stops for that insertion point

• 🔀 This is separate from the single-step stop-on-first-match optimization

💡 Tips

• 📝 Start simple — Test each step independently as a regular profile before combining into a multi-step sequence

• 🍪 Use cookie reuse — Enable reuseCookie: true when the next step depends on session state from the previous step

• 📍 Use insertion point reuse — Set insertionPoint: "same" when the entire attack chain should target the same parameter

• 🔢 Order matters — Steps execute in array order; place prerequisite steps first

• 🔍 Debug with Scanner tab — Use the Scanner tab to see per-request details for each step