Burp Suite

Intruder

Burp Suite Intruder – Attack Type Methodology & Decision Framework

Summary

1. Objective
2. Pre-Execution Controls & Safeguards
3. Attack Escalation Strategy
4. Attack Selection Decision Tree
5. Attack Type Definitions & Execution Models

1. Objective

This document defines a methodology for selecting and executing Intruder attack types during authorized web application security assessments.

2. Pre-Execution Controls & Safeguards

Before selecting an attack type:

1. Estimate request count.
2. Confirm brute-force authorization.
3. Assess rate limiting.
4. Monitor for account lockout.
5. Log evidence properly.
6. Configure appropriate request throttling settings.

3. Attack Escalation Strategy

Methodology recommends escalation:

1. Begin with Sniper to identify response behavior.
2. Use Battering Ram when duplication logic is suspected.
3. Apply Pitchfork for known credential pairs.
4. Escalate to Cluster Bomb only when justified and authorized, as this mode may significantly increase request volume.

4. Attack Selection Decision Tree

                        ┌────────────────────────────┐
                        │  What are you testing?     │
                        └──────────────┬─────────────┘
                                       │
                    ┌──────────────────┴──────────────────┐
                    │                                     │
        ┌───────────▼───────────┐             ┌──────────▼──────────┐
        │ Single parameter only?│             │ Multiple parameters? │
        └───────────┬───────────┘             └──────────┬──────────┘
                    │ Yes                                  │ Yes
                    ▼                                      ▼
           ┌───────────────────┐              ┌────────────────────────────┐
           │ Use SNIPER        │              │ Do parameters need         │
           │                   │              │ identical values?          │
           └───────────────────┘              └──────────────┬─────────────┘
                                                             │
                                            ┌────────────────┴───────────────┐
                                            │                                │
                                           Yes                               No
                                            │                                │
                                            ▼                                ▼
                                ┌────────────────────┐        ┌────────────────────────────┐
                                │ Use BATTERING RAM  │        │ Are values correlated?     │
                                │ (same payload      │        │ (e.g., known pairs)        │
                                │ everywhere)        │        └──────────────┬─────────────┘
                                └────────────────────┘                       │
                                                                      ┌───────┴────────┐
                                                                      │                │
                                                                     Yes               No
                                                                      │                │
                                                                      ▼                ▼
                                                         ┌──────────────────┐   ┌─────────────────────┐
                                                         │ Use PITCHFORK    │   │ Use CLUSTER BOMB    │
                                                         │ (parallel lists) │   │ (all combinations)  │
                                                         └──────────────────┘   └─────────────────────┘

5. Attack Type Definitions & Execution Models

5.1 Sniper Attack

Purpose

Tests a single injection position sequentially using one payload set.

Target Example

username=§user§&password=pass

Payload Set (Single List)

payload1
payload2
payload3
payload4
payload5
payload6

Execution Model

Request Volume Formula

$N$

Use Cases

• Testing single parameter behavior
• Username enumeration
• Initial response pattern analysis

Operational Risk

Low (linear execution)

5.2 Battering Ram Attack

Purpose

Injects the same payload into multiple positions simultaneously.

Target Example

username=§user§&password=§password§

Payload Set (Single List)

payload1
payload2
payload3
payload4
payload5
payload6

Execution Model

Request Volume Formula

$N$

Use Cases

• Testing identical credentials
• Scenarios where parameters are expected to match

Operational Risk

Low

5.3 Pitchfork Attack

Purpose

Iterates through multiple payload sets in parallel (index-based).

Target Example

username=§user§&password=§password§

Payload Sets

Set 1

set1_item1
set1_item2
set1_item3

Set 2

set2_item1
set2_item2
set2_item3

Execution Model

Request Volume Formula

$\min(N_1, N_2, ..., N_n)$

Use Cases

• Testing known username/password pairs
• Validating parameter dependencies

Operational Risk

Moderate

5.4 Cluster Bomb Attack

Purpose

Tests all possible combinations across multiple payload sets (cartesian product).

Target Example

username=§user§&password=§password§

Payload Sets

Set 1

set1_item1
set1_item2
set1_item3

Set 2

set2_item1
set2_item2
set2_item3

Execution Model (Example)

Request Volume Formula

$N1 \times N2$

Use Cases

• Assessment of authentication control robustness

Operational Risk

High (exponential growth potential)

Active Directory

Network

OSI Model

Definition

The OSI Model describes Internet using 7 layers:

Model

Protocols

7. Application

HTTP - HTTPS - FTP - SMTP - Git - GraphQL - REST - SMB - DNS - CSRF Tokens - HTTP Headers - DNS - LDAP / LDAPS - Kerberos - SNMP - SMTP / IMAP / POP3 - RDP - SSH - NFS

6. Presentation

SSL/TLS - MIME - XML - JSON - MIME - base64 - gzip - ASN.1 - X.509 - JWT

5. Session

Sockets - WebSocket - OAuth2.0 - SAML - Session Cookies

4. Transport

TCP - UDP

3. Network

IP - IPsec - ICMP - BGP

2. Data

ARP - MAC - Ethernet - 802.1X

1. Physical

Bluetooth - Wi-Fi - USB - NFC - RFID

Protocols

HTTP - HyperText Transfer Protocol

Related pages

Related RFCs

Summary

1. Definition
2. Requests
3. Status codes
4. Responses

Definition

HyperText Transfer Protocol (HTTP)
Application layer protocol that specifies how to transmit data over the Internet. HTTP is a request-response model using a client-server architecture

Key characteristics

• Stateless protocol
• Supports multiple versions: HTTP/1.1, HTTP/2, HTTP/3 (see below)

HTTP versions HTTP/1.1 : pipelining (asynchronous requests) HTTP/2 : multiplexing and header compression (HPACK) HTTP/3 : QUIC support (UDP-based)

Note

• All example provided in this page can be found it the associated pcap file:
• This capture was generate using this Python script leveraging the scapy library.

Requests

Request definition

A request is sent by a client to a server.
The start line includes a method name, a request URI and the protocol version with a single space between each field. The following request start line specifies method GET, URI /page and protocol version HTTP/1.1:

GET /page HTTP/1.1

Requests can pass additional information using Request header fields.

Example request

Below is an example request to example.com.

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/1.0
Accept: text/html
Connection: keep-alive

Note: There are two blank lines at the end of the request, marking the end of the request.
The subsequent response can be found in the response section.

Requests methods

• A request is said safe if it does not modify server state.
• A request is cacheable if its response may be stored by the server for future reuse.

Status codes

Responses

Definition

A response is sent by the server to the client.

The start line contains:

• Protocol version
• Status code
• Reason phrase (optional)

Example start line:

HTTP/1.1 200 OK

Responses may include additional response header fields

Example Response

Below is the response from the request from previous section

HTTP/1.1 200 OK
Date: Sat, 01 Jan 1970 00:00:00 GMT

Content-Type: text/html
Content-Length: 48
Connection: keep-alive

<html>
<head><title>Example</title></head>
<body>Test Page</body>
</html>

Security considerations

HTTP is generally secured through TLS, resulting in HTTPS. Other security considerations are to be bear in mind:

• Never trust user input
• Methods Enforcement - Restrict or disable unsafe methods (cf. request methods)
• Security Headers - Implement headers such as Strict-Transport Security (enforces HTTPS-only), X-Frame-Options, Content-Security-Policy (enforces CSP) and X-Content-Type-Options (also see the [dedicated headers page])
• Response Header Validation - Ensure headers do not leak sensitive informations (e.g., server software and version)
• IP and Header Spoofing Mitigation - Validate incoming headers (cf. furnished OWASP article)

HTTP request header fields

HTTP response header fields

DNS - Domain Name System

Related pages

Related RFCs

Definition

Domain Name System (DNS)
Enables the translation from a human-readable domain name to a machine-readable IP address

Example
google.com -> 142.251.167.100

Command
nslookup (e.g., $ nslookup google.com)

Algorithm

Operates using a recursive, hierarchical lookup, sequentially querying each domain level until the authoritative record is retrieved.

From Wikipedia

In given example

1. The user attempts to access fr.wikipedia.org, triggering a DNS resolution request.
2. The DNS resolver queries the root NS, or root name server (here a.root-servers.net) to identify .org top-level domain authority.
3. root NS (a.root-servers.net) replies specifying the authoritative server for .org domain names (here a0.org.afilias-nst.info).
4. The resolver queries said server (a0.org.afilias-nst.info) for fr.wikipedia.org.
5. a0.org.afilias-nst.info answers ns0.wikimedia.org is in charge of wikipedia.org domain.
6. The resolver queries ns0.wikimedia.org for fr.wikipedia.org's IP address.
7. ns0.wikimedia.org returns 91.198.174.232.
8. The resolver delivers the IP address to the end user.

Note : In the referenced diagram, the DNS resolver is labeled Serveur DNS récursif

Structure

The DNS architecture is based on a distributed, tree-like model, structured around root servers, top-level domains, and authoritative name servers.

From Wikipedia

DNS Record Types Table

Introduction

This page provides an overview of the different DNS record types, their operational usage, and their compliance with official standards. Links to the relevant RFC pages are available at the bottom of this document.

Table of Contents

1. Address Resolution (Web / Network)
2. Mail Services and TLS Governance
3. DNSSEC – Integrity and Validation
4. Services and Applications (VoIP, SIP, Service Discovery)
5. Zone Administration and Infrastructure
6. Rare Types
7. Non-standard / Proprietary
8. Summary Table
9. RFC Datatracker Links

Address Resolution (Web / Network)

Notes

• CNAME / DNAME: Provide aliasing flexibility; a CNAME cannot coexist with other record types on the same name.
• HTTPS / SVCB: Recently standardized, replacing certain CNAME-based practices for HTTPS.

Mail Services and TLS Governance

DNSSEC – Integrity and Validation

Services and Applications (VoIP, SIP, Service Discovery)

Zone Administration and Infrastructure

Rare Types

Non-standard / Proprietary

Summary Table

The table below aggregates all DNS record types detailed in the previous sections, indicating their primary usage, DNS standard compliance, and corresponding RFC references.

RFC Datatracker Links

ARP - Address Resolution Protocol

Related pages

Related RFCs

Definition

Address Resolution Protocol (ARP)
Enables the mapping from a IPv4 address to a link-layer (MAC) address within the same local network segment

Workflow

Blueprint

1. ARP Request: A host broadcasts a request: "Who has IP X.X.X.X?"
2. ARP Reply: The host with X.X.X.X IP responds with its MAC address.
3. Resolution: The requesting host updates its ARP cache and uses given IPv4 address.

Showcase

A PCAP file demonstrating a ARP request and response is provided below.

This capture was generate using this Python script leveraging the scapy library.

ARP Cache

• Hosts store resolved IP -> MAC records mappings in a local ARP cache to reduce repeated broadcast traffic.
• Entries have a time-to-live (TTL)
• Proper cache management is critical; cf the ARP Spoofing and ARP flooding section

Proxy ARP

• Routers may respond to ARP request on behalf of remote hosts in different subnets
• Useful for legacy networks

Common attacks

ARP Spoofing

An attacker responds to an ARP request that was not meant for him, thus impersonating the original person

ARP Flooding

The attacker floods the network with ARP answers; after that, every request goes to the attacker

Security mitigations

• Static ARP entries: Configure critical hosts to prevent spoofing
• Dynamic ARP inspection (DAI): Enforce ARP validation on managed switches
• Segmentation and VLANs: Limit broadcasts to reduce attack surface
• Disable ARP gleaning

References and recommended readings

TLS/SSL

Related pages

Related RFCs

Summary

1. Definition
2. Requests
3. Status codes
4. Responses

Definition

Transport Layer Security (TLS)
Cryptographic protocol providing confidentiality, integrity and authentication for communications over a computer network.
TLS is the successor of the now depreciated Secure Socket Layer (SSL); while the terms are commonly used indistinctly, TLS is the protocol currently standardized and deployed

Key characteristics

• Relies on a three-way handshake
• Session-oriented protocol
• Provides end-to-end encryption and peer authentication
• Multiple protocol versions: SSL 1.0, SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3

Protocol versions

Deprecated and insecure versions

• SSL 1.0 - Never released
• SSL 2.0 - Cryptographically broken
• SSL 3.0 - Vulnerable to POODLE attacks
• TLS 1.0 - defined in RFC 2246 - Deprecated due to weak cryptographic primitives
• TLS 1.1 - defined in RFC 4346 - Deprecated and no longer recommended

Note : All versions listed above are deprecated and should not be used

Supported and secure versions

• TLS 1.2 - defined in RFC 5246 - updated in RFC 8446
  • Uses SHA-256 (instead of MD5 and SHA-1 combination)
  • Added AES-GCM and AES-CCM
  • Still widely deployed and used
  • Authentication is embedded in cipher suite, thus the certificate is tightly coupled to it
• TLS 1.3 - defined in RFC 8446
  • Removes insecure algorithms and features
  • Reduces handshake latency
  • Authentication and key exchange are decoupled from cipher suites (negotiated via signature_algorithm), increasing flexibility, configuration and auditing

Note

• To explore TLS interactively, check out the TLS section of the Crypto on the web page from cryptohack.org:

Handshake

TLS relies on a handshake, performed between the client and the server at connection initialization.
Make sure to read the given documentation about TLS handshake risks.
Below is a handshake overview.

TLS 1.2 handshake

1. Client Hello

   • Supported TLS versions, supported cipher suites, supported compression methods, Client nonce, extensions.

2. Server Hello

   • Selected TLS version, selected cipher suite, server nonce.

3. Certificate

   • Server X.509 certificate chain, public key.

4. ServerKeyExchange (if applicable)

   • Key exhange parameters, digital signature.

5. ClientKeyExchange

   • Pre-master secret (RSA) or client key share (ECDHE)

6. ChangeCipherSpec / Finished

   • Confirmation of negotiated parameters, handshake integrity verification.

TLS 1.3 handshake

1. Client Hello

   • Supported TLS versions, supported cipher suites, supported signature algorithms, key shares (ECDHE), extensions.

2. Server Hello

   • Selected TLS version, selected cipher suite, selected key share.

3. Ecnrypted Extensions

   • Negotiated extensions.

4. Certificate

   • Server certificate chain, authentication context.

5. CertificateVerify

   • Server proof of private key ownership

6. Finished

   • Handshake transcript verification, keys activated.

Certificates

TLS relies on X.509 certificates to authenticate servers within a public key infrastructure (PKI). Certificates are typically issued by a trusted Certificate Authority (CA).

Key considerations

• Verify that certificates are valid, unexpired, and issued by a trusted CA.
• Confirm key strength (e.g., RSA > 2048 bits).
• Check that signature algorithms are not deprecated.
• Ensure the certificate chain is complete and correctly configured.
• Confirm hostname matching.

Common attacks

Renegociation Exploiting unsafe TLS renegociation sequences Downgrade attacks Forcing a connection to use older/weaker TLS or SSL versions Cross-protocols attacks Leveraging compatibility with SSL/TLS in other services Time attacks Cipher-specific attacks BEAST Exploits TLS 1.0 CBC mode CRIME Targets TLS compression POODLE Exploit SSL 3.0 padding issued RC4 Weak stream cipher in legacy TLS. Truncation and plaintext attack Forcing premature session closure or exposing data. Heartbleed Exploits vulnerable OpenSSL heartbeat implementations TLS interception / MiTM Unauthorized inteception of traffic, usually via rogue certificates

References & recommended readings

Policies & Framework References

This section consolidates curated notes on Governance, Risk, and Compliance (GRC), as well as leading associated frameworks, including ISO 27001 and NIST CSF 2.0.

Disclaimer: All linked materials are provided for educational and professional reference purposes. Their use in operational contexts must adhere to organizational policies and authorized procedures. These documents represent internal notes; some interpretations or summaries may not fully reflect official guidance. Users are advised to consult primary sources and exercise professional judgment.

Governance, Risk & Compliance (GRC)

• GRC Overview – Notes on Governance, Risk Management, and Compliance.

ISO27001

• ISO 27001 — Testing Types – Overview of penetration testing types: external, internal, blind, double-blind, and targeted approaches.

NIST CSF 2.0

• NIST CSF 2.0 — Governance Functions – Description of the six CSF functions: Govern, Identify, Protect, Detect, Respond, Recover, with outcomes.
• NIST CSF 2.0 — Tiers & Evaluation – Explanation of implementation maturity tiers and evaluation criteria.

GRC Overview

ISO 27001 Framework Notes

This section consolidates internal notes and resources related to ISO 27001.

Disclaimer: All linked materials are intended for educational and professional reference purposes. These notes represent internal summaries; some interpretations may not fully reflect official guidance. Users should consult official ISO 27001 documentation and exercise professional judgment.

Testing & Assessments

• ISO 27001 — Testing Types – Overview of penetration testing types: external, internal, blind, double-blind, and targeted.

ISO 27001 – Testing Types

This section outlines the main types of security tests recommended under an ISO 27001 ISMS, with objectives and alternative names.

External Testing

Compromises access from outside the system.
Target: Everything visible from the Internet.

Also called: Black-box testing, External Network Assessment

Internal Testing

Assesses what an attacker can compromise once inside the network.
Target: Insider threat—employees, contractors.

Also called: Internal Network Assessment, Grey-box testing (partially)

Blind Testing

Conducted without any prior knowledge of the system.
Target: Understand what a hacker could do with no internal information.

Also called: Single-Blind Testing

Double-Blind Testing

Neither the pentester nor the security team knows the test is occurring.
Target: Evaluate both what a hacker could achieve and how quickly the team detects them.

Also called: Double-Blind Penetration Test

Targeted Testing

The tester and security team work together, focusing on specific areas.
Target: Evaluate defenses with full collaboration for selected components.

Also called: Knowledge-Based Testing, Collaborative Testing

Social Engineering Testing

Tests human and physical security controls via phishing, vishing, or on-site exercises.
Target: Assess human vulnerabilities and policy adherence.

Also called: Phishing Assessment, Human Factor Testing, Physical Security Testing

Red Teaming

Simulates a realistic, multi-vector attack combining external, internal, social engineering, and physical methods over time.
Target: Measure the organization’s overall detection and response capabilities.

Also called: Full-Scope Adversary Simulation, Adversarial Emulation

Configuration / Compliance Testing

Checks system configurations and adherence to ISO 27001 policies.
Target: Ensure technical and procedural compliance.

Also called: Audit Testing, Technical Compliance Assessment

NIST CSF 2.0 Framework References

This section consolidates internal notes and resources related to NIST Cybersecurity Framework (CSF) 2.0.

Disclaimer: All linked materials are intended for educational and professional reference purposes. These notes represent internal summaries; some interpretations may not fully reflect official guidance. Users should consult official NIST CSF documentation and exercise professional judgment.

Governance & Core Functions

• NIST CSF 2.0 — Governance Functions – Detailed description of the six CSF functions: Govern, Identify, Protect, Detect, Respond, Recover, with outcomes.

Implementation & Maturity

• NIST CSF 2.0 — Tiers & Evaluation – Explanation of maturity tiers, evaluation factors, and assessments.

NIST CSF 2.0 — Governance Functions

This document focuses on the functional components of the NIST Cybersecurity Framework (CSF) 2.0 and their role in cybersecurity governance and operations.

Govern

Core governance function

• Establish and maintain cybersecurity policies
• Align cybersecurity objectives with organizational mission and strategy
• Define roles, responsibilities, and accountability
• Support strategic planning and decision-making
• Oversee cybersecurity risk management and risk ownership at the executive level

Outcome: Governance structures, oversight mechanisms, and cybersecurity leadership alignment.

Identify

• Understand cybersecurity risks to the organization
• Identify and classify assets, systems, and business processes
• Perform risk-based assessments aligned with risk appetite
• Improve policies, procedures, and prioritization mechanisms
• Identify and assess third-party and supply chain cybersecurity risks

Outcome: Asset inventory and risk-informed security strategy.

Protect

• Implement safeguards to mitigate identified risks
• Enforce security policies through technical and organizational controls
• Protect organizational assets, systems, and data
• Apply preventive security controls, including:
  • Identity and Access Management (IAM / PAM)
  • Security awareness and training
  • Data protection mechanisms
  • System and application hardening

Outcome: Effective implementation of preventive security measures.

Detect

• Identify anomalous activity and potential cyber incidents
• Establish detection and alerting capabilities

Outcome: Continuous monitoring and detection capabilities (e.g. SIEM, SOC).

Respond

• Develop and execute incident response processes
• Contain, analyze, and mitigate cybersecurity incidents

Outcome: Structured incident response plans and coordinated actions.

Recover

• Restore systems, services, and business operations
• Improve resilience and reduce long-term impact

Outcome: Recovery plans, business continuity, and crisis communication.

NIST CSF 2.0 — Implementation Tiers & Evaluation

This document describes the NIST CSF implementation tiers and the criteria used to assess cybersecurity maturity.

Implementation Tiers

The tiers reflect the maturity of an organization’s cybersecurity risk management practices.

Tier 1 — Partial

• Ad hoc or reactive cybersecurity practices
• No formalized risk management processes

Assessment: Very low preparedness and limited control.

Tier 2 — Risk-Informed

• Awareness of cybersecurity risks
• Risk considerations influence decision-making
• Processes are informal and inconsistently applied

Assessment: Capable teams, but lacking standardized and documented processes.

Tier 3 — Repeatable

• Documented and implemented cybersecurity processes
• Formal risk management policies approved and enforced

Assessment: Structured and consistent, with limited adaptability.

Tier 4 — Adaptive

• Continuous improvement of cybersecurity practices
• Use of advanced and current risk management techniques
• Rapid adaptation to emerging threats

Assessment: Mature, proactive, and resilient cybersecurity posture.

Tier Evaluation Factors

Key criteria used to assess tier placement:

• Maturity of risk management processes
• Integration of cybersecurity into daily operations
• Ability to adapt to evolving threat landscapes

Evaluation Process

• Identification, control, and reduction of risks
• Formalization, communication, and enforcement of cybersecurity policies
• Measurement of overall cybersecurity maturity and preparedness