📝Creating Rules

This guide walks you through creating Smart Scan rules step by step.

1️⃣ Step 1: Open the Rule Editor

1. Go to Burp Bounty Pro > Rules tab

2. Click Add to create a new rule

3. 🪟 The rule editor dialog opens

2️⃣ Step 2: Basic Information

Field	Description	Example
📝 Rule Name	Unique identifier	My_Custom_Rule
✅ Enabled	Whether the rule is active	true
📄 Description	What the rule does	Detect Spring Boot and test actuators

3️⃣ Step 3: Define Match Conditions (IF)

Add one or more passive profile conditions that must be met before the rule triggers.

➕ Adding a Condition

1. Select the condition type:

   • 📨 Passive Request — Match against HTTP requests

   • 📩 Passive Response — Match against HTTP responses

2. Select the passive profile to reference

3. Set the logic operator (for the second condition onward):

   • ✅ AND — Both this condition and the previous must match

   • 🔀 OR — Either this condition or the previous must match

📚 Condition Examples

🔍 Single condition:

IF Passive Response profile "Wordpress detection" matches

✅ Multiple AND conditions:

IF Passive Request profile "Fortinet_Request" matches
AND Passive Response profile "Fortinet_Panel" matches

🔀 Multiple OR conditions:

IF Passive Request profile "CouchDB_Request" matches
OR Passive Response profile "CouchDB_Response" matches

⚙️ Logic Evaluation

When combining AND and OR:

Condition1 AND Condition2 OR Condition3

This evaluates as:

(Condition1 AND Condition2) OR Condition3

✅ AND has higher precedence than OR.

4️⃣ Step 4: Define Execute Actions (THEN)

📝 Execute Specific Profiles

Run one or more named active profiles:

THEN execute:
  - Profile "CVE-2021-44228_RCE_Log4j"
  - Profile "CVE-2021-44228_RCE_Log4j_GETPOST"
  - Profile "CVE-2021-44228_RCE_Log4j_urlEncode"

🏷️ Execute by Tag

Run all active profiles that have a specific tag:

THEN execute all profiles with tag "XSS"

This is more maintainable than listing individual profiles — when you add new XSS profiles and tag them, they're automatically included in the rule.

🎯 Match Scope

Choose how many times the action executes:

Scope	Behavior
🔄 All Matches	Execute for every match of the passive condition
1️⃣ First Match	Execute only for the first match (avoids redundant scanning)

All Matches is the default and recommended for most cases. Use First Match when:

• 🔄 The passive profile matches frequently and you only need one test

• ⬇️ You want to reduce scan load on the target

• 🖥️ The vulnerability check only needs to run once per host

5️⃣ Step 5: Save the Rule

💾 Click Save to store the rule. It becomes immediately active if Enabled is set to true.

💡 Tips for Effective Rules

🖥️ Use Technology Detection as Triggers

Create passive profiles that detect specific technologies, then trigger targeted CVE profiles:

IF detect WordPress → THEN run WordPress CVE profiles
IF detect Jira → THEN run Jira CVE profiles
IF detect Spring Boot → THEN run Spring Boot Actuator profiles

💉 Use Parameter Detection for Vulnerability Classes

Create passive profiles that detect interesting parameters, then trigger the appropriate vulnerability profiles:

IF detect SQLi-like parameters → THEN run SQLi profiles
IF detect redirect/URL parameters → THEN run Open Redirect + SSRF profiles
IF detect file/path parameters → THEN run LFI/Path Traversal profiles

🔗 Combine Request and Response Conditions

For more precise targeting, require both request and response conditions:

IF request matches "Fortinet_Request" (URL pattern)
AND response matches "Fortinet_Panel" (page content)
THEN execute CVE-2018-13379_FortiOS_Creds_Disclosure

This avoids false triggers from URL patterns alone.

📦 Start with Default Rules

Review the 27 default rules for patterns and inspiration. Most common scenarios are already covered.

🏷️ Tag-Based Rules for Broad Scanning

Use tag-based execution for flexible, broad rules:

IF detect any request → THEN execute tag "Open Redirect"

⚠️ Warning: Broad rules like these can generate a lot of traffic. Only enable them when needed and consider using "First Match" scope.