Brup Suite - Intruder

Posted Mar 4, 2020 Updated Dec 1, 2025

By Hyoeun Choi

78 min read

Burp Intruder

Strategic Selection of Attack Types and Payload Positioning

Intruder’s efficiency starts with the accurate mapping of the Attack Position and Attack Type. When dealing with complex parameter combinations, you must accurately understand the behavior mechanism of each type.

Intruder Workflow and Configuration

The basic workflow begins by capturing a request in the Proxy or Repeater and sending it to Intruder (Send to Intruder, shortcut Ctrl+I).

Positions Tab: Setting Attack Points

The first task is to designate the position where the parameter to be modified, or the payload, will be injected. Burp selects all parameter values by default, but for precise testing, you should press the Clear § button to initialize, then drag only the specific parts you want to test and mark them with Add §.

Sniper

Uses a single payload set and tests one position at a time.

Mechanism: When positions A and B are designated, it first sequentially substitutes payloads into A while keeping B at its original value. Once testing for A is complete, it restores A to its original value and substitutes payloads into B.
Scenario: Identifying which parameter is vulnerable to SQL Injection in a form with 5 parameters. Intruder tests the first parameter while maintaining the original values for the rest, then moves to the second parameter.
Application: Suitable for individually isolating and testing which of several parameters is vulnerable.

Battering ram

Uses a single payload set but injects the same value into all positions simultaneously.

Mechanism: Payload ‘X’ is inserted into positions A and B simultaneously, and the request is sent.
Scenario: When a User ID must exist in both the URL path and the POST Body XML data simultaneously, and the logic proceeds only if the two values match.
Application: Useful for testing integrity verification logic where the same value must be included in the HTTP request header and body, or when an identifier is distributed across multiple locations.

Pitchfork

Uses multiple payload sets and iterates through each set in parallel.

Mechanism: Payload Set 1 is assigned to position A, and Payload Set 2 is assigned to position B. The first value of Set 1 is combined with the first value of Set 2 for the request. (1:1 mapping)
Scenario: Performing Credential Stuffing using an obtained username:password dump list. Since Password A only needs to be tried for User A, unnecessary combinations can be reduced.
Application: Used when there is a clear correlation between data (e.g., an ID and the correct token pair for that ID).

Cluster bomb

Attempts all combinations (Cartesian Product) of multiple payload sets.

Mechanism: For the first value of Payload Set 1, all values of Payload Set 2 are substituted sequentially. Then, it moves to the next value of Set 1.
Scenario: Attempting Brute Force using a list of User IDs and a common password dictionary file when the administrator account password is unknown. (Try all passwords for User A, try all passwords for User B…)
Application: Used when an exhaustive search of all input possibilities for form data is required. Note that the number of requests increases exponentially, so care must be taken with range settings.

Correlation Between Payload Sets and Attack Types

The Payload Sets section at the top of the Payloads tab is closely linked to the Attack Type set in the Positions tab. You must accurately understand this structure to design complex attack scenarios involving multiple variables.

Activation of Payload Sets: The number of active Sets is determined by the number of markers (§) designated in the Positions tab and the selected Attack Type. For example, if Pitchfork or Cluster bomb is selected and two parameters are marked, the Payload Sets are divided into 1 and 2, and each must be configured independently.
Independent Configuration per Set: Different Payload types can be applied to each Set. For instance, a hybrid configuration is possible where the first Set (Username) is set to Simple list and the second Set (Password) is set to Runtime file for large-scale processing.

Key Payload Types and Advanced Usage Strategies

Burp offers various Payload Types, and selecting the appropriate type for the situation determines the efficiency of the test.

Simple list and Runtime file

While most basic, there is a significant difference in terms of memory management.

Simple list: Used when pasting values directly into the text box or loading relatively small dictionary files. All items are loaded into memory.
Runtime file: Essential when using huge dictionary files (e.g., the entire rockyou.txt) exceeding hundreds of megabytes. Burp does not load the entire file into memory but reads it line by line in a streaming manner at runtime, preventing Out Of Memory (OOM) issues during large-scale brute forcing.

Custom iterator

Powerful when you need to combine multiple string sets to create a single sophisticated payload. You can create complex string combinations even while using a single Position (Sniper mode, etc.).

Structure: Create virtual slots like Position 1, 2, 3…, and assign separate lists to each slot. Then, specify the Separator that goes between each slot.
Usage Example: Useful when combining [Filename List] + [Separator] + [Extension List] to test for admin.bak, admin_old, etc. This allows for a combination effect similar to Cluster bomb while maintaining easier request management.

Recursive grep

A method that extracts specific data from a previous response and uses it immediately as the payload for the next request.

Core Use: Essential when Anti-CSRF tokens are renewed with every request or when testing multi-step authentication flows.
Constraints: Since the result of the preceding request becomes the input for the succeeding request, concurrency is not possible. You must strictly set it to single thread (Maximum concurrent requests: 1 in Resource Pool) for it to work correctly. The ‘Grep - Extract’ setting in the Options tab must be configured beforehand to activate this.

Null payloads

Generates empty values instead of actual payloads to repeat requests.

Core Use:
- When sending the same request simultaneously to identify Race Condition vulnerabilities.
- When exploiting loopholes in business logic, such as manipulating view counts or vote counts.
- You can specify the number of repetitions via the Generate payload count option or set Continue indefinitely for an infinite loop.

Character frobber & Bit flipper

Systematically modifies specific characters or bits of the input value.

Usage Example: Useful when analyzing encrypted session tokens or serialized data. Used to diagnose cryptographic vulnerabilities like CBC Bit Flipping by observing whether the application returns a decryption error or authenticates as a different user when specific bytes of the token are changed.

Simple list substitution has a high probability of being blocked by WAFs or application input validation logic. The ‘Payload Processing’ section defines transformation rules to be applied immediately before the payload is transmitted. Rules are applied sequentially in the set order (Top-down).

Add prefix / Add suffix: Automatically appends ', ), ` – `, etc., to the front or back of the payload during SQL Injection attacks. This allows you to complete the query syntax without modifying the original dictionary file.
Encode / Decode: Converts specific special characters to Base64, URL encoding, Hex, etc. For example, if a WAF blocks the <script> keyword, you can automate bypass attempts by encoding it in Base64.
Hash: Hashes the payload using MD5, SHA256, etc., before transmission. Used when testing logic where passwords are hashed on the client side, allowing you to use a plaintext dictionary but convert it to hash values right before sending.
Invoke Burp extension: Calls Python or Java extensions written by the user when complex logic not solvable by default rules (e.g., custom encryption, digital signature generation) is required.

Payload Encoding Considerations

The ‘Payload Encoding’ section located at the bottom of the Payloads tab is enabled by default and automatically URL-encodes characters that have special functions in URLs (&, =, ?, spaces, etc.).

Default Behavior: Characters like /, ?, =, &, +, \, ", ', ;, < , > (space) are checked, so if these characters are included in the payload, they are converted to the %xx format.
When to Disable:
- JSON/XML API Testing: When injecting payloads into a JSON body ({"key": "§payload§"}), applying URL encoding may break the syntax or cause the server to fail to recognize the value properly. You must check this option carefully and disable it if necessary during API pentesting.
- Double Encoding Prevention: If URL encoding was already applied in Payload Processing rules, this section might encode it again, causing double encoding. Disable it if this is not the intended attack vector.

Resource Pool: Request Control and Stability Assurance

The Resource Pool tab is the control center that manages the load Intruder attacks place on the target server and the local network environment. Increasing scan speed is not always the answer; precise settings are required to prevent network bottlenecks, avoid server DoS (Denial of Service) states, and evade detection by security equipment (WAF/IPS).

Maximum concurrent requests (Thread Control)

This setting determines the number of threads for HTTP requests sent simultaneously.

Default Settings and Optimization: Burp’s default is usually set around 10. However, if the target server’s processing capacity is small or network bandwidth is narrow, a high thread count can frequently cause Timeouts or connection errors, slowing down the overall diagnosis. Conversely, when targeting high-performance servers within an internal network, you can increase threads to speed up the process.
Mandatory Setting for Recursive Grep: When using the Recursive grep type in the Payloads tab, since the previous response value must be used for the next request, parallel processing is logically impossible. In this case, you must set this value to 1 to force sequential request transmission.
Race Condition Testing: To trigger race condition vulnerabilities, you need to push many requests momentarily. In this case, set the thread count high (20~50 or more), but using the Turbo Intruder extension is more effective than the Java-based Intruder.

Throttle (Delay between requests)

Assigns an intentional delay between requests. This has two main purposes:

Prevent Server Overload: Adjusts requests per second (RPS) to continue scanning stably without exhausting server resources.
Security Detection Evasion (Stealth): If a large number of requests occur in a short time, firewalls or IPS may block the IP. Adding a delay makes the traffic look like general user traffic.

Fixed delay: Waits for a fixed amount of time (milliseconds) between every request.
Variable delay (Randomness): Security monitoring systems use heuristic algorithms to detect mechanical patterns (e.g., requests exactly every 0.5 seconds) and flag them as bots. Enabling the Add random variations to delay option adds randomness (Jitter) to the delay time, helping to hide these mechanical patterns. For example, if you add 50% variation to a 1000ms delay, the request interval will be randomly determined between 500ms and 1500ms.

Strategic Resource Pool Configuration Examples

Create new resource pool: You can create independent pools for each Intruder tab. It is recommended to separate and manage them so that running different attacks simultaneously (e.g., one brute force, one fuzzing) does not affect each other’s speed.
System-wide pool: Selecting Use default resource pool follows Burp’s global settings. Use this option if you want to control the overall network bandwidth when running multiple scans simultaneously.

Senior testers prefer ‘uninterrupted connections’ over unconditional high speed. It is an expert habit to check the target server’s response speed in Repeater or a separate terminal before starting the attack, and then configure the Resource Pool by calculating threads and delay accordingly. Especially in environments with strict WAFs, a 1 Thread + Variable Delay combination is a valid strategy to extract data slowly over time (Low and Slow).

Turbo Intruder: Extreme Speed and Flexibility

Burp Intruder is powerful, but due to its Java GUI-based architecture and memory management methods, it has limitations in handling massive requests (millions or more) or attacks requiring microsecond (µs) level precise timing control. Turbo Intruder, developed by PortSwigger researcher James Kettle, is an extension designed to overcome these constraints, combining a custom HTTP stack and Python scripting to offer incomparable speed and flexibility.

Architecture and Working Principle

Turbo Intruder defines attack logic via Python scripts instead of GUI settings. Internally, it uses a high-performance HTTP stack written in Go, capable of achieving speeds dozens to hundreds of times faster (tens of thousands of RPS depending on the environment) than the existing Intruder. Additionally, it natively supports HTTP Pipelining and HTTP/2 Multiplexing to test server processing limits to the extreme.

Core Components: Python Interface

Turbo Intruder scripts consist largely of two functions:

queueRequests(target, wordlists): Responsible for starting the attack and stacking requests into the engine queue. Here, you configure the RequestEngine which controls connection counts, pipelining settings, request rates, etc.
handleResponse(req, interesting): A callback function invoked whenever a response returns from the server. Here, you analyze the response code or search for specific strings to decide whether to display it in the results table (interesting).

Key Use Cases and Code Strategies

1. Race Condition Testing Turbo Intruder’s most powerful feature is triggering Race Conditions using the Gate mechanism. While general multi-threading has slightly different server arrival times due to network latency, Turbo Intruder sends requests right up to the server, holds the last byte, and then sends the last byte on all connections simultaneously when the signal (gate) drops, implementing perfect concurrency.

  
def queueRequests(target, wordlists):
    # Engine config: pipelining=1 is standard, can be higher for Race Conditions
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=30,
                           requestsPerConnection=100,
                           pipeline=False
                           )

    # 1. Normal request queuing
    for word in open('/usr/share/dict/words'):
        engine.queue(target.req, word.rstrip())

    # 2. Gate setup example for Race Condition
    # Group 10 requests under a gate named 'race'
    for i in range(10):
        engine.queue(target.req, gate='race')
    
    # Open the gate to send 10 requests simultaneously
    engine.openGate('race')

def handleResponse(req, interesting):
    # Record only 200 OK responses to the table
    if req.status == 200:
        table.add(req)

2. High-Speed Fuzzing and Brute Force When targeting servers that support HTTP Pipelining, you can maximize throughput by using pipelining technology, which sends consecutive requests without waiting for responses within a single TCP connection. Using the pipeline=True option and appropriate requestsPerConnection settings allows you to substitute huge dictionary files in a short time.

3. Complex Signature Bypassing If a dynamically generated hash value (HMAC) or timestamp must be included in the header for each request, setting this up with the standard Intruder’s Macro feature is very difficult. In Turbo Intruder, you can import Python libraries to calculate the signature immediately at the time of request generation and modify the header before transmission.

Result Analysis and Filtering

Turbo Intruder does not save all responses. For memory efficiency, it only saves requests where table.add(req) is called in the handleResponse function. Therefore, when writing scripts, you must filter precisely using code based on response size, status codes, inclusion of specific keywords, etc. This allows you to retain only meaningful vulnerability data without gigabytes of log files.

Senior Engineer’s Tips

Use Decorators: You can use decorators to easily apply custom headers or payload variations.
Consider Server Stability: Turbo Intruder’s speed can place a fatal load on the server. For live targets, start with low concurrentConnections and increase gradually.
Utilize External Libraries: If necessary, you can modify sys.path to load locally installed Python libraries. This allows you to perform complex encryption logic or data processing.

Settings Tab: Precision Control and Stability Assurance

The Settings tab (including sub-items of the Options tab in older versions) is where the technical details of the attack are fine-tuned. Beyond simply executing an attack, it controls network connection methods, error recovery strategies, and memory management to guarantee the stability of large-scale scans that last for long periods. We analyze key setting items that a Senior Engineer must check.

Request Headers: Communication Protocol Control

Defines how HTTP request headers generated by Burp are handled.

Update Content-Length header: Checked by default. When a payload is inserted, the length of the body changes; this option must be active for Burp to recalculate the exact Content-Length value and insert it into the header. If disabled, the server may determine that the request is incomplete or excessive, returning a Timeout or 400 Bad Request. Unless it is a special case like HTTP Smuggling testing, leave this on.
Set Connection: close: Forcibly adds Connection: close to the request header. HTTP/1.1 uses Keep-Alive by default, but when sending large volumes of short requests with multiple threads like Intruder, closing sockets immediately can be advantageous for resource management. However, disable this when using pipelining or when server overhead needs to be reduced.

Error Handling: Network Instability Response

When sending thousands of requests, connection failures can occur due to temporary network disconnections or momentary server overload. This section sets the resilience to continue the attack without interruption.

Number of retries on network failure: The number of retries upon connection failure. The default is 3. Increase this value when routing through unstable networks or overseas networks to prevent False Negatives.
Pause before retry: The wait time before retrying. If a WAF has logic to temporarily block an IP and then release it, giving this a generous time (e.g., 2000ms or more) can induce a retry after the block is lifted.

Attack Results: Memory and Storage Optimization

Intruder basically saves all request and response data to memory (or temporary files). If this setting is incorrect when processing tens of thousands of requests, Burp may freeze or force close due to OOM (Out Of Memory) errors.

Make a full grep: Uncheck to save memory for result table performance. However, keep it on for detailed analysis.
Discard response bodies: The most important option for large-scale scans. It saves only headers and metadata, discarding the response body. Since the body is discarded after the Grep - Extract function operates, data extraction occurs normally while memory usage is drastically reduced. If you only need to check status codes or extracted values, this must be enabled.

Auto-pause attack: Conditional Automatic Suspension Strategy

When performing large-scale attacks, continuing to send meaningless requests even after a specific event has occurred is a waste of time and a major cause of log pollution. The Auto-pause attack feature analyzes the content of the response body in real-time and pauses the attack immediately when set conditions are met. This is very useful for senior pentesters to monitor the attack process and secure control.

Core Purpose of the Feature:
- Stop Immediately on Success: For example, if a login succeeds during a brute force attack, there is no need to proceed further. Detecting the success indicator and stopping immediately prevents unnecessary traffic.
- Block Detection and Protection: If the attack is not stopped when a WAF block page or “Rate Limit Exceeded” message appears, the IP may be permanently blocked. Detecting this and stopping helps protect the IP.
- Session Expiration Response: If the session is disconnected during the attack and redirects to the login page, all subsequent attacks are recorded as failures (False Negative). This detects the event to time session re-establishment.
Setting Options Details:
- Pause if an expression… appears: Pauses when a specific string (e.g., “Welcome”, “Error: 500”, “Captcha required”) appears in the response. Mainly used when a vulnerability is found or blocking has started.
- Pause if an expression… is missing: Pauses when a specific string (e.g., “Logged in as”, normal footer text) disappears from the response. Useful when the server goes down or the page structure changes due to session expiration.
Match type:
- Simple string: Simple text matching.
- Regex: Powerful for detecting dynamic patterns. Used to catch changing success messages like User ID: \d{4} or specific error code formats.

Using this feature allows for immediate response (resuming or changing settings) after grasping the situation, as the attack will be paused upon the occurrence of critical events even if you leave your seat after queuing tens of thousands of requests.

Redirections: Redirection Tracking Policy and Analysis Strategy

Web browsers automatically follow 3xx responses (Redirection) from servers to show the final destination, but in security testing, especially automated attacks using Intruder, this behavior can rather hinder vulnerability identification. This section defines Intruder’s behavior when encountering 3xx responses.

Follow redirections (Tracking Policy)
- Never (Default and Recommended): Does not follow redirections and immediately shows the 3xx response as the result.
  - Expert Usage: Essential for most Fuzzing and Brute Force scenarios. For example, the surest indicator distinguishing ‘Failure (200 OK)’ from ‘Success (302 Found -> Dashboard)’ during login attempts is the status code. If redirections are followed, success also returns a final ‘200 OK (Dashboard)’, making it indistinguishable from failure responses by status code alone. Also, when checking for Open Redirect vulnerabilities, you must verify the Location header value directly, so set this to Never.
- On-site only: Follows redirections only within the same host (domain/port). Stops if redirected to an external site.
- In-scope only: Follows redirections only to URLs defined in the Scope of the Target tab. Useful for preventing requests outside the attack target range.
- Always: Follows all redirections regardless of destination. Beware of falling into infinite redirection loops.
Process cookies in redirections (Session Maintenance)
- Enabled only when configured to follow redirections (On-site, Always, etc.).
- Working Principle: Servers often issue Session IDs via the Set-Cookie header when giving a redirection response (302). If this option is unchecked, Intruder will not include the cookie just issued when sending the redirected next request, causing the session to break (resulting in bouncing back to the login page). Must be checked when deeply attacking pages with complex authentication flows.

HTTP Connection & Version Control: Protocol-Level Optimization and Bypass

This section deals with strategic settings to verify the target server’s protocol processing logic and bypass security equipment, beyond simple “connection speed”.

HTTP/1 connection reuse (TCP Keep-Alive)
- Function: Reuses the single TCP connection (Socket) after establishing it to send multiple HTTP requests without disconnecting. Significantly increases scan speed by reducing 3-way handshake overhead.
- Strategic Usage:
  - Speed Optimization (Default Recommended): It is absolutely advantageous to keep this option on when transmitting large volumes of payloads.
  - When to Disable: When testing the behavior of Load Balancers (L4/L7). For example, to check if routing is done to different backend servers for every connection, you must disconnect (Connection teardown) every time instead of reusing the connection. Also, some WAFs block if too many requests occur in a single session, so connections are intentionally dropped to evade this.
HTTP version (HTTP/2 Force & Downgrade)
- Function: Forces the HTTP version to be used in this attack, regardless of Burp’s project-wide settings.
- Core Use Case (WAF Bypass): Many WAFs and security devices strictly inspect HTTP/1.1 traffic but often have flawed parsing logic or loose inspection rules for HTTP/2 traffic.
  - HTTP/2 Force: Even if it appeared as HTTP/1.1 in Repeater or Proxy, if the server supports it, force HTTP/2 transmission to test if WAF detection can be bypassed.
  - Protocol Downgrade: Conversely, even if the server uses HTTP/2 by default, force downgrade to HTTP/1.1 to diagnose Host header parsing differences or Request Smuggling vulnerabilities.

Grep: Precise Analysis and Filtering Strategy for Response Data

In an Intruder attack sending tens of thousands of requests, the simple fact that “it was sent” is not important. What matters is identifying “which response is different”. The Grep functions located in the Settings tab (or Options tab in older versions) are filters and detectors that find meaningful signals within numerous response data. Senior Pentesters do not rely on visual inspection but data-fy attack results through Grep settings.

Grep - Match: Anomaly Detection (Flagging)

Inspects whether a specific string is included in the response body and displays it as a checkbox in the results table. This becomes the most critical indicator when success/failure cannot be judged by HTTP Status Code alone.

Overcoming Functional Limits: Many web applications return 200 OK even on login failure, or output error messages on a 200 OK page instead of a 302 redirection when an error occurs. In these cases, sorting by status code is meaningless.
Key Use Cases:
- Error Message Detection: Register keywords like SQL syntax, ORA-, Exception, stack trace during Fuzzing to identify SQL Injection or information disclosure vulnerabilities.
- Success/Failure Discrimination: During Brute Force attacks, register keywords that appear only upon login success like Welcome, Logout, My Page, or conversely, Invalid password which appears on failure, to find items with different patterns.
Setting Tips:
- Case sensitive match: Distinguishes case. Checking this increases accuracy, but if you don’t know how the developer wrote the error message, unchecking it increases versatility.
- Exclude HTTP headers: Generally set to inspect only the Body to reduce False Positives caused by strings coincidentally included in headers (cookie values, etc.).

Grep - Extract: Data Extraction and Mining

Extracts a specific part of the response data and creates it as a separate column in the results table. Essential when going beyond simple detection to harvest data or use it as material for the next attack.

Working Principle: Press the ‘Define’ button and drag the area you want to extract from the response sample; Burp automatically designates the start (Start delimiter) and end (End delimiter) strings. For complex patterns, you can write Regular Expressions (Regex) directly.
Key Use Cases:
- Information Leak Check: List DB version information, internal IP addresses, file paths, etc., included inside error messages for use in reporting.
- Token Harvesting: Extract Session IDs, CSRF Tokens, API Keys, etc., issued after login.
- Recursive Grep Integration: Link the data extracted here with the ‘Recursive grep’ type in the Payloads tab to automate scenarios requiring CSRF tokens, like posting on a bulletin board or changing passwords.
Caution: Set a Maximum length for data extraction to restrict unnecessarily long HTML codes from loading into the table and wasting memory.

Grep - Payloads: Reflection Verification

Verifies if the payload I sent returns included as-is in the response value.

Key Use Case: Most powerful when finding Reflected XSS (Cross-Site Scripting) vulnerabilities. For example, if <script>alert(1)</script> is sent as a payload and this string exists as-is in the response body, the possibility of XSS is very high.
Working Principle: It dynamically inspects whether the payload used in that request exists in the response, rather than looking for a fixed string.
Match against pre-URL-encoded payloads: Even if the payload was transmitted URL-encoded, it may appear decoded in the response. Enabling this option attempts matching based on the original string before encoding to increase accuracy.

Senior Engineer’s Grep Strategy

The core of Grep settings is “Noise Reduction”.

Before the attack, analyze normal responses and error responses in Repeater.
Find a Unique String that clearly distinguishes the two responses and register it in Grep - Match.
Techniques are also frequently used that not only check for existence but utilize ‘Invert match’ (checks if the string is missing) to find abnormal responses where footer or copyright text common to all pages is broken or missing.

Burp Intruder

Attack Type과 페이로드 포지셔닝의 전략적 선택

Intruder의 효율성은 공격 지점(Position)과 공격 유형(Attack Type)의 정확한 매핑에서 시작됩니다. 복잡한 매개변수 조합을 다룰 때 각 유형의 동작 방식을 정확히 이해해야 합니다.

Intruder 워크플로우 및 구성

기본적인 워크플로우는 Proxy나 Repeater 등에서 요청을 캡처하여 Intruder로 전송(Send to Intruder, 단축키 Ctrl+I)하는 것으로 시작됩니다.

Positions 탭: 공격 지점 설정

가장 먼저 수행해야 할 작업은 변조할 파라미터, 즉 페이로드(Payload)가 주입될 위치를 지정하는 것입니다. Burp는 기본적으로 모든 파라미터 값을 자동으로 선택하지만, 정밀한 테스트를 위해서는 Clear § 버튼을 눌러 초기화한 후, 테스트하려는 특정 부분만 드래그하여 Add §로 마킹해야 합니다.