# Smart Scan

Smart Scan is one of the most powerful features of Burp Bounty Pro. It uses **Rules** to automatically trigger active scanning profiles when specific passive conditions are detected — creating intelligent, context-aware scanning workflows.

## 💡 Concept

Smart Scan follows an **IF-THEN** pattern:

```
IF passive profile(s) match → THEN execute active profile(s)
```

This means:

1. 👁️ **Passive profiles** continuously analyze all traffic (requests and responses)
2. 📋 When a passive profile matches, **rules** check if conditions are met
3. 🎯 If conditions are met, **active profiles** are automatically executed against the matched request

## ❓ Why Smart Scan?

Instead of running all active profiles against every request (which is slow and noisy), Smart Scan:

* ⚡ **Reduces scan time** — Only tests relevant vulnerabilities for each target
* 🎯 **Reduces false positives** — Only scans when context suggests a vulnerability is likely
* 🤖 **Automates workflows** — No manual intervention needed to target specific technologies
* 🖥️ **Enables technology-specific testing** — Detects WordPress, Jira, Spring, etc. and runs their CVE profiles

## ⚙️ How It Works

### 📘 Example: WordPress Detection

1. 👁️ **Passive Response profile** `Wordpress detection` matches responses containing WordPress indicators (e.g., `wp-content`, `wp-includes`)
2. 📋 **Rule** `Wordpress_Rule` is configured:
   * **IF**: Passive Response profile `Wordpress detection` matches
   * **THEN**: Execute active profiles: `Wordpress_user_enum_oembed`, `Wordpress_user_enum_json`, `Wordpress_directory_listing`, `Wordpress_Path_Traversal`, `Wordpress_Config_Accessible`, etc.
3. 🎯 **Active scanning** automatically begins on the matched request with WordPress-specific profiles

### 📘 Example: SQL Injection Parameter Detection

1. 👁️ **Passive Request profile** `SQLi_Parameters` detects parameters like `id=`, `user_id=`, `query=`
2. 📋 **Rule** `SQLi_Rule` is configured:
   * **IF**: Passive Request profile `SQLi_Parameters` matches
   * **THEN**: Execute active profiles: `SQLi`, `SQLi_Timebased_Encoded_Space`
3. 🎯 **Active scanning** targets only the requests with suspicious parameters

## 📋 Rule Structure

Each rule consists of:

### 🔍 Match Conditions (IF)

One or more passive profile matches that must be satisfied:

* 📨 **Passive Request profiles** — Match patterns in HTTP requests
* 📩 **Passive Response profiles** — Match patterns in HTTP responses
* 🔗 **Logic operators** — Combine conditions with AND/OR:
  * **AND** — All conditions must match
  * **OR** — At least one condition must match

### 🎯 Execute Actions (THEN)

What to do when conditions are met:

* 📝 **Execute specific profiles** — Run named active profiles
* 🏷️ **Execute profiles by tag** — Run all active profiles with a specific tag (e.g., all profiles tagged "XSS")
* 🎯 **Match scope** — Execute on "All Matches" or "First Match" only

## 🔄 Smart Scan Flow

```
HTTP Traffic
  │
  ├─ 📨 Passive Request Profile matches request
  │   └─ 📋 Check Rules → IF condition met → 🎯 Execute Active Profiles on this request
  │
  └─ 📩 Passive Response Profile matches response
      └─ 📋 Check Rules → IF condition met → 🎯 Execute Active Profiles on this request
```

## 📊 Smart Scanner Tab

Smart Scan results are displayed in the dedicated **Scanners** > **Smart** sub-tab:

* Lists each evaluated request with host, method, URL, and matched rules
* Shows which active profiles were launched and scan count
* Includes request/response viewers for inspection

## ⚙️ Configuration

### ⚡ Scanner Settings

When Smart Scan rules trigger active scans automatically, they use default scanner settings (**10 threads**, **10 concurrency**, **10 RPS**). These defaults are suitable for most scenarios.

When you manually launch a Smart Scan via the context menu, the URL Filter popup appears with context-aware settings:

| Setting                    | Description                                    |
| -------------------------- | ---------------------------------------------- |
| 🧵 **Threads**             | Number of threads for the scan                 |
| 🔀 **Passive Concurrency** | Maximum concurrent passive profile evaluations |
| 🔀 **Active Concurrency**  | Maximum concurrent active scan connections     |
| 📈 **Requests per second** | Rate limit for the scan                        |

See [Scan Control](https://docs.bountysecurity.ai/scanning/scan-control) for details on per-scan performance configuration.

### ✅ Enabling/Disabling Rules

* Go to **Burp Bounty Pro** > **Rules** tab
* Enable/disable individual rules with the checkbox
* Only enabled rules participate in Smart Scan

## 📦 Default Rules

Burp Bounty Pro ships with 28 pre-configured rules covering:

* 🖥️ **Technology detection** — WordPress, Jira, Spring Boot, Drupal, Symfony, Weblogic, CouchDB, etc.
* 💉 **Vulnerability parameters** — SQLi, XSS, RCE, LFI, SSRF, SSTI, Open Redirect
* 🌐 **Bulk scanning** — Disabled by default: scan all requests with specific profile groups

See [Default Rules](https://docs.bountysecurity.ai/reference/default-rules) for the complete list.

## 📖 Creating Custom Rules

See [Creating Rules](https://docs.bountysecurity.ai/rules/creating-rules) for a step-by-step guide.