Penetration Testing Tools

Burp Decoder: Tool for decoding and encoding various data formats, such as Base64, URL encoding, and hexadecimal, for web security testing.

The function of Burp Decoder is relatively simple. As a coding and decoding tool in Burp Suite, it can convert raw data into various encoding formats and hashes. The interface is as shown below, which mainly consists of three parts: input field, output field, and encoding and decoding options.

The input field is to input the original data that needs to be decoded. You can fill in or paste it directly here, or you can use [Send to Decoder] in the context menu of other Burp tools; the output field is to display the result of decoding the input field. Both the input field and the output field support both text and Hex formats.

The encoding and decoding options consist of three options: Decode as, Encode as, and Hash. In actual use, it can be set according to the needs of the scene. For encoding and decoding options, currently eight forms of format conversion are supported: URL, HTML, Base64, ASCII, hexadecimal, octal, binary, and GZIP. Hash hashing supports SHA, SHA-224, SHA-256, Conversion of SHA-384, SHA-512, MD2, and MD5 formats. More importantly, for the same data, we can perform multiple encoding and decoding conversions on the Decoder interface. As shown below:

How to use Burp Comparer

Burp Comparer: A feature in Burp Suite for comparing two HTTP responses or requests to identify differences, aiding in vulnerability analysis.

Burp Comparer mainly provides a visual difference comparison function in Burp Suite to compare and analyze the difference between two data. The scenarios in use may be:

1. During the process of enumerating user names, compare and analyze the difference in the server-side feedback results when the login is successful and failed.
2. When using Intruder to attack, for different server-side responses, you can quickly analyze the difference between the two responses.
3. When performing blind injection testing of SQL injection, compare the difference between the two response messages and determine the relationship between the response results and the injection conditions.

The interface is as shown below:

The use of Comparer mainly consists of two links, first data loading, and then difference analysis.

Commonly used methods for loading Comparer data are: forwarding from other Burp tools through the context menu, pasting directly, and loading from files. When loading is complete, if you select two different request or response messages, the issued comparison button will be activated, and you can choose text comparison or byte comparison. As shown below:

If you click [words] or [bytes], you will enter the comparison interface, and the page will automatically display the difference in data through the background color. As shown below:

Among them, text comparison (words) refers to comparing the difference between two data through text, such as HTML; and byte comparison (bytes) refers to comparing twice through hexadecimal form. content differences. As shown in the picture below, pay attention to the color marking of different contents.

Burp Suite Sequencer is a tool used to detect the randomness quality of data samples. It is usually used to detect whether access tokens are predictable and whether password reset tokens are predictable. Through Sequencer’s data sample analysis, it can be easily This effectively reduces the risk of these critical data being falsified.

How to use Burp Suite Sequencer

As a random number analysis tool, Burp Sequencer may have unpredictable effects on the system during the analysis process. If you are not very familiar with the system, it is recommended not to perform data analysis in a production environment.

The steps to use it are roughly as follows:

1. First, confirm that Burp Suite is installed correctly, and configure the browser proxy to run normally.
2. From the historical log records of Burp Proxy, look for token or similar parameters, return to right-click to pop up the context menu, and click [Send to Sequencer].

Enter the Live Capture panel of Burp Sequencer, select the record just sent, and click [Configure] to configure the token or parameters that need to be analyzed.

In the parameter configuration dialog box that pops up, select the parameter value and click the [OK] button to complete the parameter setting.

Click [Select Live Capture] to start obtaining parameter values.

When the total number of captured parameter values ​​is greater than 100, click [pause] or [stop] to perform data analysis. Click [Analyze now] to perform random analysis of the data.

When the analysis is completed, you can see various charts of the analysis results.

Of course, we can also save the obtained data and load parameters from the file for data analysis the next time it is used. Save the data as shown below.

When I use it again, I can directly load the data for analysis.

Burp Suite Sequencer Analysis Options

The purpose of setting the analysis options is mainly to control the token or parameters, what kind of processing needs to be done during the data analysis process, and what type of randomness analysis needs to be done. It mainly consists of two parts: Token Handling and Token Analysis .

Token Handling mainly controls how tokens are processed in data analysis. Its setting interface is as shown in the figure below:

Pad short tokens at start/end means that if the tokens generated by the application have variable length, then These tokens need to be populated before data analysis to facilitate statistical testing.

You can choose whether to pad at the beginning or at the end of each token. In most cases, padding at the beginning is most appropriate. Pad with means you can specify the characters that will be used for padding. In most cases, numeric or ASCII hex-encoded tokens, padded with “0” are most appropriate. Base64-decode before analysis indicates whether to perform base64 decoding during data analysis. If the token uses base64 encoding, you need to check this option.

Token Analysis is mainly used to control the type of randomness analysis of data. We can select multiple analysis types, and can also enable or disable each character type-level and byte-level testing individually. Sometimes, it is useful to perform a preliminary analysis with all analysis types enabled before disabling certain analysis types in order to better understand the characteristics of the token, or to isolate any unusual properties exhibited by the sample. Its setting interface is as follows:

The above two options are character type levels that control data analysis, which include Count and Transitions . Count refers to analyzing the distribution of characters used at each position within the token. If it is a randomly generated sample, the distribution of characters used is likely to be roughly uniform.

Analyze the statistical probability at each position that the token is a randomly generated distribution. The analysis result chart is as follows:

Transitions refer to changes between consecutive symbols in the analyzed sample data. If the sample is randomly generated, a character appearing at a given position is equally likely to be changed by the next token in any of the characters used at that position. Statistically analyze the probability of token random generation to change at each position. The analysis result chart is as follows:

The following settings are byte-level tests used to control data analysis, which are more powerful than character-level tests. With byte-level analysis enabled, each token is converted into a set of bytes, with the total number of bits determined by the size of the character set at each character position. It contains the following seven test types.

FIPS monobit test – It tests and analyzes the distribution of 0s and 1s at each bit position. If the sample is randomly generated, the number of 1s and 0s is likely to be approximately equal. The Burp Sequencer records whether each bit passed or failed the FIPS test observation. It is worth noting that the formal specification for FIPS testing assumes a total sample size of 20,000. If you want to obtain results that are as stringent as the FIPS specification, you should make sure to achieve a sample size of 20,000 tokens. The analysis result chart is as follows:

FIPS poker test – This test divides the j-bit sequence into four consecutive, non-overlapping groups, then derives 4 numbers, counts the number of times each number appears out of 16 possible digits, and uses the chi-square test to evaluate the numbers Distribution.

If the sample is generated randomly, the distribution of this number may be approximately uniform. At each position, through this testing method, analyze the probability that the token is a randomly generated distribution. The analysis result chart is as follows:

FIPS runs tests – This test divides a continuous sequence of bits with the same value into segments at each position, and then calculates the length of each segment as 1, 2, 3, 4, 5, and 6 and above. If the samples are randomly generated, then the length of these segments is likely to be within a range determined by the size of the sample set.

At each position, using this analysis method, observe the probability that the token is randomly generated. The analysis result chart is as follows:

FIPS long runs test – This test divides a continuous sequence of bits with the same value into segments at each position and counts the longest segment. If the samples are randomly generated, the number of longest segments is likely to be within a range determined by the size of the sample set. At each position, using this analysis method, observe the probability that the token is the longest segment randomly generated. The analysis result chart is as follows:

Spectral tests – These tests do a complex analysis at each position in the bit sequence and can identify evidence that certain samples are non-random by other statistical tests. The sample test passes through a sequence of bits and treats each series of consecutive numbers as coordinates in a multidimensional space and determines each position of a point in this space by plotting it on these coordinates. If the samples are randomly generated, the distribution of points in this space is likely to be roughly uniform; the appearance of clusters within this space indicates that the data are likely to be non-random. At each position, using this analysis method, observe the probability that the token occurs randomly. The analysis result chart is as follows:

Correlation test – compares the entropy between a token sample with the same value in each position and a short token sample with a different value in each position to test for any correlation between the values ​​in different bit positions inside the token Statistically significant relationship. If the sample is generated randomly, the value at a given bit position is equally likely to be accompanied by a one or a zero at any other bit position. At each position, use this analysis method to observe the probability that the token was randomly generated.

To prevent arbitrary results when a certain degree of correlation is observed between two bits, the test is adjusted so that its significance level is based on the significance level of the bits tested at the level of all other bits. The analysis result chart is as follows:

Compressoion test – This test does not use the statistical methods used in other tests, but counts the amount of entropy at each position in the bit sequence through a simple and intuitive indicator.

The analysis method attempts to compress each position of the bit sequence using standard ZLIB, and the results show that when it is compressed, the size of the bit sequence is reduced in proportion, and higher compression levels indicate that the data is less likely to be randomly generated. The analysis result chart is as follows:

Burp Suite Sequencer simple example

The most dangerous usage of Burp Suite Sequencer would likely be in the hands of malicious actors who are attempting to exploit vulnerabilities in web applications for nefarious purposes. While Burp Suite Sequencer itself is a legitimate security tool used by ethical hackers and security professionals to assess the randomness and quality of tokens, session identifiers, and other elements within web applications, it could be misused by attackers in several ways:

• Session Fixation Attacks: Malicious actors could use Burp Suite Sequencer to identify weaknesses in session identifiers generated by web applications. By exploiting predictable or weak session identifiers, attackers could potentially hijack user sessions, gaining unauthorized access to sensitive data or functionality.
• Cryptographic Weaknesses: Burp Suite Sequencer can help identify weaknesses in cryptographic algorithms used to generate tokens or encrypt sensitive data within web applications. Attackers could exploit these weaknesses to bypass security controls, decrypt confidential information, or launch cryptographic attacks such as chosen plaintext attacks or brute-force attacks.
• Authentication Bypass: If Burp Suite Sequencer reveals patterns or weaknesses in authentication tokens or mechanisms, attackers could leverage this information to bypass authentication controls and gain unauthorized access to restricted areas of web applications.
• Predictable CSRF Tokens: Cross-Site Request Forgery (CSRF) tokens are meant to prevent unauthorized actions initiated by malicious websites. If Burp Suite Sequencer identifies CSRF tokens that are predictable or easily guessable, attackers could craft malicious requests to perform actions on behalf of authenticated users without their consent.
• Data Tampering: By analyzing the randomness of tokens or parameters, attackers could identify opportunities to tamper with data exchanged between clients and servers, potentially leading to data manipulation, injection attacks, or other forms of exploitation.

It’s important to note that the danger lies not in the tool itself, but in how it’s used. Ethical hackers and security professionals use Burp Suite Sequencer to uncover vulnerabilities and strengthen the security of web applications. However, in the wrong hands, it could be used to exploit vulnerabilities for malicious purposes, posing significant risks to the confidentiality, integrity, and availability of web applications and their data. Therefore, it’s crucial for organizations to implement appropriate security measures and monitoring to detect and mitigate potential misuse of tools like Burp Suite Sequencer.

Burp Suite Repeater is a tool within the Burp Suite software package, which is widely used by security professionals for web application security testing. Burp Suite Repeater is a testing tool for manual verification of HTTP messages.

It is usually used for message analysis of server-side responses after replaying request responses multiple times and manually modifying request messages.

Usage of Burp Repeater

During the penetration testing process, we often use Repeater to perform message verification and analysis of requests and responses, such as modifying request parameters to verify input vulnerabilities; modifying request parameters to verify logic override; and capturing characteristic request messages from interception history records. Make a request for replay.

The operation interface of Burp Suite Repeater is as shown below:

The request message area is the detailed information of the request message sent by the client.

Burp Repeater has a request number for each request. When we double-click on the number of the request encoding, we can modify the name of the request.

This is to facilitate multiple requests. Used for making notes or distinctions when sending messages. Under the number, there is a [send] button. After we edit the requested message, click this button to send the request to the server.

The response message area is the feedback message from the server after clicking the [send] button for the corresponding request message. By modifying the parameters of the request message to compare and analyze the differences between each response message, it can better help us analyze possible vulnerabilities in the system.

When we use Burp Suite Repeater, we usually use it in conjunction with other Burp tools, such as Proxy’s history records, Target’s site map, etc., through the right-click menu on other tools, execute [Send to Repeater], Jump to the Repeater tab, then modify the request message, request replay, data analysis and vulnerability verification.

Burp Repeater settings

Different from the settings of other Burp tools, Repeater’s optional settings menu is located in the menu bar at the top of the entire interface, as shown in the figure:

Its settings mainly include the following:

• Update Content-Length
  This option is used to control whether Burp automatically updates the Content-Length in the request header.
• Unpack and compress (Unpack gzip / deflate) This option is mainly used to control whether Burp automatically decompresses or compresses the content of the server-side response.
• Jump control (Follow redirections) This option is mainly used to control whether Burp automatically follows the server to make request jumps. For example, if the server returns a status code of 302, whether it will follow the response and jump to the URL pointed to by 302. It has 4 options, namely Never, On-site only, In-scope only, and Always, among which Never, Always jump is easy to understand. Intra-site jump refers to the current jump within the same site; target domain jump means that the domain configured in the target scope can jump;
• Process cookies in redirections If this option is selected, the cookie information set during the jump will be brought to the URL page pointed to by the jump and can be submitted.
• Other operations (Action) point to other tool components of Burp through submenus.

Here’s how Burp Suite Repeater works:

• Capture Request: Initially, you capture HTTP requests using another tool within Burp Suite called the Proxy. This captures all HTTP traffic between your browser and the web server.
• Send to Repeater: Once you’ve captured a request you want to inspect or manipulate further, you can send it to Burp Suite Repeater.
• Manual Manipulation: In the Repeater interface, you can manually adjust various parts of the HTTP request, such as headers, parameters, or the request body. This allows for fine-tuning and customization of the request.
• Reissue Request: After making any necessary modifications, you can reissue the request to the server directly from within Repeater.
• View Response: Once the server responds to the modified request, you can view the response in Repeater. This allows you to observe how the server reacts to different inputs and configurations.

Example of Burp Repeater attack

The most dangerous usage of Burp Suite Repeater would involve its exploitation by malicious actors to perform various types of attacks against web applications. Burp Suite Repeater, while primarily a tool for security professionals to manually manipulate and reissue individual HTTP requests, can be misused in several ways:

• Injection Attacks: Malicious actors could use Burp Suite Repeater to perform injection attacks such as SQL injection, command injection, or XSS (Cross-Site Scripting). By manipulating parameters or request payloads and observing the responses, attackers can attempt to exploit vulnerabilities in the application’s input validation and security mechanisms.
• Session Hijacking: If Burp Suite Repeater identifies weaknesses in session management or authentication mechanisms, attackers could exploit these vulnerabilities to hijack user sessions. By capturing and replaying session tokens or cookies, attackers could gain unauthorized access to sensitive user accounts or perform actions on behalf of authenticated users.
• Parameter Tampering: Attackers could use Burp Suite Repeater to tamper with parameters, headers, or other parts of HTTP requests to modify application behavior or access unauthorized functionality. This could lead to data manipulation, privilege escalation, or unauthorized access to sensitive information.
• Brute-Force Attacks: Burp Suite Repeater can be used to automate and iterate over different values or combinations of parameters, headers, or payloads in order to perform brute-force attacks. This could be used, for example, to guess passwords, authentication tokens, or other sensitive information.
• API Abuse: Malicious actors could abuse APIs (Application Programming Interfaces) by using Burp Suite Repeater to manipulate API requests and responses. This could lead to unauthorized access to sensitive data, API rate limiting evasion, or denial-of-service attacks against API endpoints.

It’s important to emphasize that Burp Suite Repeater itself is a legitimate security tool used by ethical hackers and security professionals to identify and mitigate vulnerabilities in web applications. However, in the wrong hands, it could be misused to exploit weaknesses for malicious purposes, potentially causing significant harm to individuals, organizations, and their data. Therefore, it’s crucial for organizations to implement strong security measures, including proper access controls, monitoring, and auditing, to prevent misuse of tools like Burp Suite Repeater and protect against potential attacks.

Burp Suite Repeater is particularly useful for testing and debugging web applications, as it provides a controlled environment for experimenting with individual requests and observing their effects in real-time. It helps security professionals identify vulnerabilities, assess the impact of potential attacks, and verify the effectiveness of security measures.

Burp Suite Intruder is a module within the Burp Suite toolkit that specializes in automated attacks against web applications. It’s the go-to tool for performing brute force attacks, fuzzing, and other types of automated testing to identify vulnerabilities and weaknesses in web applications.

This tool actually gives you attack requests, for example; If you have more than 20 payloads that you want to inject, instead of sending these payloads to the website one by one, Burp Intruder automatically sends these payloads to the web applications. And the payloads you send can actually identify security vulnerabilities in web applications.

Subtabs in Burp Suite Intruder

• Positions: This sub-tab allows us to select the attack type and configure where we want the payload to be inserted in the request template.
• Payloads: This subtab allows us to choose to insert the payload (payload) into each position we defined in the previous subtab. For example, we can choose to load items from the dictionary as the payload. As for how to insert the payload into the request template, depending on the attack type we selected in the Positions subtab; there are many payload types we can choose from (from a simple dictionary to a regular expression based on the server response), and the Payloads subtab also Allows us to change the behavior of the attacker (Intruder) and the payload. For example, we can define some preprocessing rules to apply to each payload. These preprocessing rules include – adding prefixes or suffixes, matching and replacing, or when If the payload matches a defined regular expression, it will be skipped, etc.
• Resource Pool: This sub-tab mainly allows us to allocate resources between tasks, which is not particularly useful for Burp Community Edition; Burp Suite Professional Edition allows us to run various types of automated tasks in the Burp background, and Resource Pool is Where we want to manually allocate available memory and computer processing power between these automated tasks and Intruder; if we can’t access the background automated tasks, there is little point in using the Resource Pool (this article uses the Burp Community Edition, so it does not No access to background automation tasks).
• Settings: Burp Suite Intruder allows us to configure attack behavior in the Settings subtab. The settings here mainly apply to how Burp handles the results and how Burp handles the attack itself; for example, we can choose to mark requests that contain specified text fragments, or define how Burp handles them. Redirect (3xx) response.

Tips: Fuzz testing means that we take a set of data and apply it to a parameter to test the target function or see if something exists; for example, we can choose to perform “endpoint fuzz testing” in a web application, which will Add each item in the dictionary to the end of the request message and send it multiple times and see how the web server responds
(for example http://MACHINE_IP/WORD_GOES_HERE).

Here’s what Burp Suite Intruder brings to the table:

• Customizable Attacks: With Burp Suite Intruder, users can customize and fine-tune their attacks to target specific parameters, headers, or parts of HTTP requests. This includes the ability to modify payloads, payloads positions, and attack configurations.
• Brute Force Attacks: Intruder excels at conducting brute force attacks, allowing users to systematically test for weak or guessable credentials, session tokens, and other sensitive information.
• Fuzzing: Users can leverage Burp Suite Intruder to perform fuzzing attacks, where variations of input data are systematically injected into parameters and fields to uncover unexpected behavior, vulnerabilities, or weaknesses.
• Cluster Bomb Attacks: Intruder supports cluster bomb attacks, where multiple payloads are tested against each position in the payload set. This allows for more comprehensive testing of different payload combinations.
• Response Handling: Intruder provides powerful response handling capabilities, allowing users to define custom rules for identifying and analyzing interesting responses, such as error messages, status codes, or application behavior.

A simple example of using Burp Suite Intruder to conduct a brute force attack against a login page:

• Configure Target: First, we need to configure Burp Suite to intercept traffic between our browser and the target login page. Set up Burp Suite’s proxy to intercept HTTP/S traffic and configure your browser to use Burp Suite as the proxy.
• Capture Login Request: Navigate to the login page of the target application and enter some arbitrary credentials. Ensure that Burp Suite intercepts the login request.
• Send to Intruder: Once the login request is intercepted, right-click on it in the Burp Suite Proxy history and select “Send to Intruder.”
• Configure Intruder: In Burp Suite Intruder, navigate to the “Positions” tab and specify the parameters you want to attack (e.g., username and password fields). You can use placeholders like § to mark positions for attack.
• Payloads: Go to the “Payloads” tab and configure your payload options. For a brute force attack, you might want to use a predefined wordlist or create a custom payload set with various combinations of usernames and passwords.
• Attack: After configuring payloads, navigate to the “Options” tab to configure any additional attack settings, such as request timing or attack concurrency. Once ready, click the “Start Attack” button to begin the brute force attack.
• Analyze Results: Burp Suite Intruder will automatically send the attack requests with different payloads and analyze the responses. Pay attention to any responses indicating successful login attempts or authentication failures.
• Exploit: If successful credentials are found, you can use them to gain unauthorized access to the target application, allowing you to further exploit vulnerabilities or access sensitive information.

How to use Burp Suite Intruder

Intruder is an extremely powerful automated testing tool in Burp Suite. It is usually used by system security penetration testers in various task testing scenarios. The main contents we learn here is:

• Intruder usage scenarios and operation steps
• Payload type and processing
• Payload location and attack type
• Options
• Intruder attack and result analysis

Make sure you read How to use Burp Suite proxy

Burp Suite Intruder usage scenarios

During the penetration testing process, we often use Burp Intruder. Its working principle is: Intruder modifies various request parameters based on the original request data to obtain different request responses. In each request, Intruder usually carries one or more effective attack loads (Payload), replays the attack at different locations, and obtains the required characteristic data through comparison and analysis of the response data. Burp Intruder is usually used in the following scenarios:

1. Identifier enumeration Web applications often use identifiers to reference data information such as users, accounts, assets, etc. For example, username, file ID and account number.
2. Extracting Useful Data In some scenarios, instead of simply identifying valid identifiers, you need to extract some other data via simple identifiers. For example, you want to obtain the standard nicknames and ages of all users in their personal space through the user’s personal space ID.
3. Fuzz testing many input-based vulnerabilities such as SQL injection, cross-site scripting and file path traversal can detect applications by submitting various test strings through request parameters and analyzing error messages and other anomalies. Due to the size and complexity of the application, performing this testing manually is a time-consuming and tedious process. In such a scenario, you can set up the payload to automatically fuzz the web application through Burp Intruder.

Generally speaking, using Burp Intruder for testing mainly follows the following steps:

• Confirm that Burp Suite is installed correctly and starts normally, and the browser proxy settings are completed.
• Enter the Burp Proxy tab and turn off the proxy interception function.
• Go to the History subtab, find the request logs that may have problems, and send them to Intruder through the right-click menu.

Go to the Intruder tab and open the Target and Positions sub-tabs. At this time, you will see the request message sent in the previous step.

Because we understand that the basis of the Burp Intruder attack is to set a certain number of attack payloads at the location specified by the original request information just sent, and use the Payload to send a request to obtain the response message.

By default, Burp Intruder will set the request parameters and cookie parameters to Payload position, and add $ to the prefix, as shown in the red position in the figure above. When sending a request, the parameter identified by $ will be replaced with Payload.

On the right side of the Position interface, there are four buttons [Add $], [Clear $], [Auto $], and [Refresh $], which are used to control whether the parameters in the request message are replaced by the Payload during the sending process. If you do not want is replaced, select this parameter and click [Clear $] to remove the parameter prefix $.

When we open the Payload sub-tab, select Payload generation or selection strategy. By default, “Simple list” is selected. Of course, you can also select other Payload types through the drop-down or add them manually.

• At this point, we return to the Position interface, click [Start attack] in the upper right corner of the interface to launch the attack.
• Burp will automatically open a new interface, including the attack execution status, HTTP status code, length and other result information.

We can select one of the communication information to view the details of the request message and response message.

• Many times, in order to better indicate whether the response message contains the information we need, we usually configure the Options options before launching an attack. The most commonly used one is regular expression matching (Grep-Match).
• Alternatively, we can use the filters in the Results tab to filter the result information.
• At the same time, we can specify the columns displayed in the results tab, and we can set them in the menu Columns.
• Finally, select the column we need and click the [Save] button to save the attack results.

The above are the steps that Burp Suite Intruder completes once. In actual use, there will be more or less changes according to each person’s usage habits. The more detailed configuration involved in each link will be explained in more detail in the following chapters.

Payload type and processing

In the Payload tab of Burp Intruder, there are settings options for the Payload collection, including 18 commonly used Payload types.

• Simple list – the simplest payload type. By configuring a string list as the payload, you can also add the string list manually or load the string list from a file.
  • On this operation interface, in the selected Payload list, a set of simple Payload lists have been predefined, including XSS scripts, CGI scripts, SQL injection scripts, numbers, uppercase letters, lowercase letters, user names, and passwords. , field names of form fields, IIS file names and directory names, etc., which greatly facilitates the use of penetration testers.
• Runtime file – specifies the f
  • When we specify the Payload type used in position 1 of the Payload set as Runtime file, the Payload Options below will automatically change to a file selection button and input box. When we click [select file] When selecting a file, the dialog box shown in the picture will pop up, select the specified Payload file. When running, Burp Intruder will read each line of the file as a payload.
• Custom iterator – This is a powerful Payload. It has a total of 8 placeholders. Each placeholder can specify the Payload type of a simple list, and then according to the number of placeholders, it is matched with each simple list. Cartesian product is performed on the Payload to generate the final Payload list.
• Character substitution – As the name suggests, this type of payload generates a new payload by replacing a predefined string. For example, if the predefined string is ABCD and is set according to the replacement rules, the values ​​of AB will be enumerated and a new payload will be generated.
• Case modification—Replace predefined strings according to case rules. For example, if the predefined string is Peter Wiener, then a new Payload will be generated according to the settings you set.
• Recursive grep – This payload type is mainly used in scenarios where valid data is extracted from the server. It is necessary to first extract the data from the server’s response as the payload, and then replace the position of the payload to carry out the attack. Its data comes from the original response message. Based on the original response, Grep rules are configured in the Payload’s Options (Options), and then the data is extracted according to grep before the attack can occur.
• Illegal Unicode – Replace the characters themselves with the specified illegal Unicode encoding in payloads, and generate one or more payloads from these payload lists. This payload can be useful when trying to circumvent input validation based on pattern matching, for example when defending against directory traversal attacks by matching the expected encoding of ../ and .. sequences.
• Character blocks– This type of payload refers to using a given input string to generate character blocks of a specified size according to the specified settings, in the form of generating a string of a specified length. It usually uses bounds testing or buffer overflow.
• Number type– This type of payload refers to generating a series of numbers as payload according to the configuration.
• Date type (Dates) – This type of payload generates a series of dates based on configuration.
• Brute forcer – This type of payload generates a payload containing all permutations of a specified character set with a specific length. It is usually used to generate enumerated dictionaries.
• Null payloads – The payload generated by this payload type has an empty string value. During an attack, the same request needs to be executed repeatedly. This payload is very useful in scenarios where the original request is not modified in any way. It can be used for various attacks, such as cookie sequence analysis, application layer DoS, or keep-alive session tokens used in other intermittent experiments.
• Character frobber– The generation rule of this type of payload is: modify the value of each character position of the specified string in sequence, and each time the ASCII code of the character is incremented on the original character. It is typically used in testing systems that use complex session token components to track session state. When you modify the value of a single character in the session token and your session is still processed, it is likely that the token actually Your session is not being used to track it.
• Bit flipper – The generation rule of this type of Payload is: modify the preset Payload original value in sequence according to the bits.
• Username generator – This type of payload is mainly used for automatic generation of usernames and email accounts.
• ECB block shuffler – This type of payload is a payload generator based on the ECB encryption mode.
  • You can click to read this article to learn more about the encryption mode. The principle is that each group of 64-bit data in the ECB encryption mode is independent of each other. By changing the position of the grouped data, it is possible to verify whether the application is vulnerable to attacks.
• Extension generated – This type of payload is based on the Burp plug-in to generate the payload value. Therefore, the Burp Payload generation plug-in must be installed and configured before use, and an Intruder payload generator must be registered in the plug-in for calling here.
• Copy other payload – This type of payload copies parameters from other locations to the payload location as a new payload value. It is usually suitable for request messages with multiple parameters.
  • Its usage scenarios may be: 1. Two different parameters need to use the same value. For example, when a user registers, the password setting will be entered twice, and the value is exactly the same. This Payload type can be used. 2. In a request, the value of one parameter is a value generated by a script on the front end based on the value of another parameter. This Payload type can be used. Its setting interface and parameters are relatively simple, as shown in the figure below, where the index value of the Payload position points to the value of the Payload.

Payload location and attack type

First, let’s take a look at the setting interface of the Payload positions tab:

From the picture above, we can see that the setting of the Payload position is based on the original message of the HTTP request as the motherboard, using a pair of § characters to mark the Payload position, these two numbers directly contain the text content of the motherboard.

When we have marked a payload in a special position in the request message, when launching the attack, Burp Intruder will place a payload value in the given special position, replacing the entire position marked with the § symbol. As shown in the figure above, the § symbols after the parameter id indicate Payload position 1, and the § symbols after name indicate Payload position 2.

This value corresponds to the value of the Payload set in the Payload setting. We can edit the Payload location in the middle of the message editor, which is mainly controlled by the four buttons on the right.

• [Add §]——Add a Payload position mark at the current cursor position
• [Clear §]——Clear all Payload location flags or clear the selected Payload location flags
• [Auto §] – Make a guess about the parameters that may need to be marked in the message content. The mark is the Payload location. After the automatic setting, manual selection is made to determine which locations need to be passed in the Payload. Currently, Burp supports automatic selection of parameter types: 1. URL request parameters 2. Body parameters 3. Cookie parameters 4. Composite parameter attributes, such as file names when uploading files 5. XML data 6. JSON data Although Burp supports it by default These types of parameters are automatically marked as payload locations, but if they are for node attribute values ​​like XML or JSON, they still need to be specified manually.
• [Refresh]——Refresh the colored part of the message content.
• [Clear]——Clear all contents in the message editor.

Above the message editor, there is a drop-down selection box, Attack Type. Burp Intruder supports multiple methods of simulated attacks using payload. Currently, there are only the following 4 types.

Sniper mode (Sniper) – It uses a set of Payload sets to replace the text marked by § in the Payload position (only one Payload position can be used in an attack) (and the text that is not marked by § will not be affected). The server makes a request, usually used to test whether there are vulnerabilities in the request parameters.

Battering ram mode (Battering ram) – It uses a single Payload set, replaces the text marked with § in the Payload position (and the text that is not marked with § will not be affected), makes a request to the server, and sniper The difference between the modes is that if there are multiple parameters and they are all Payload position flags, the Payload value used is the same, while the sniper mode can only use one Payload position flag.

Pitchfork mode (Pitchfork) – It can use multiple sets of payload sets to traverse all payloads at each different payload mark position (up to 20). For example, if there are two Payload flag positions, the first Payload value is A and B, and the second Payload value is C and D, then when an attack is launched, a total of two attacks will be launched, and the Payload used in the first time will be They are A and C respectively, and the payloads used for the second time are B and D respectively.

Cluster bomb mode (Cluster bomb) It can use multiple sets of payload sets to traverse all payloads in sequence at each different payload mark position (up to 20). The main difference from Pitchfork mode is that the payload data executed is the product of payload groups. For example, if there are two Payload flag positions, the first Payload value is A and B, and the second Payload value is C and D, then when an attack is launched, a total of four attacks will be launched, and the first Payload used will be They are A and C respectively, the payloads used for the second time are A and D respectively, the payloads used for the third time are B and C respectively, and the payloads used for the fourth time are B and D respectively.

Burp Suite Intruder Options

Optional settings mainly include request header settings, request engine settings, attack result settings, grep match, grep extract, grep payloads, and redirection settings. During use, you can make settings before attacking or adjust these options during the attack.

Request Headers – This setting is mainly used to control the header information of the request message. It consists of two options: Update Content-Length header and Set Connection: close . If the Update Content-Length header is selected, Burp Intruder adds or updates the Content-Length header in each request to the correct value for the length of the HTTP body of the request.

This feature is typically used for attacks that insert a variable-length payload into the body of a templated HTTP request. If the correct value is not specified, the target server may return an error and may respond with an incomplete request. Or it might wait indefinitely for a request to continue receiving data. Set Connection: close If selected, it means Burp Intruder adds or updates a connection header with a value of “close” in each request message, which will execute more quickly.

In some cases (when the server itself does not return a valid Content-Length or Transfer-Encoding header), checking this option may allow attacks.

Request Engine Settings (Request Engine) – This setting is mainly used to control Burp Intruder attacks. Proper use of these parameters can complete the attack process more effectively.

It has the following parameters: Number of threads , Number of retries on network failure , number of retries when the network fails, Pause before retry, Pause interval before retry (milliseconds), Throttle between requests request delay (milliseconds), Start time, how long after launching the attack to start execution.

Attack Results Settings (Attack Results) – This setting is mainly used to control what information is captured from the attack results. Its parameters are: Store requests/responses to save request/response messages,

Make unmodified baseline to record the message content of the request motherboard, Use denial-of-service mode to use Dos mode, tore full payloads to store all Payload values.

Grep Match – This setting is mainly used to extract the result items from the response message. If they match, they are marked in a new column added in the attack results to facilitate sorting and data extraction. For example, in password guessing attacks, scanning messages such as “Password Incorrect” or “Login Successful” can find successful logins; in testing SQL injection vulnerabilities, scanning messages containing “ODBC”, “Error”, etc. can identify vulnerable parameters.

Its options include Match type to indicate matching expressions or simple strings, Case sensitive match to indicate whether it is case sensitive, and Exclude HTTP headers to include HTTP headers when matching.

Grep Extract – These settings can be used to extract useful information from response messages. For each item configured in the list, Burp increments a new result column containing the text extracted from that item. You can then sort the data extracted by this column (by clicking the column header).

This option is useful from application data mining and can support a wide range of attacks. For example, if you are looping through a series of document IDs, you can extract the page titles of each document looking for interesting items. If you find a feature that returns user details for other applications, you can duplicate and retrieve the relevant user by user ID looking for administrative accounts and even passwords.

If the “Forgot Password” function takes a username as a parameter and returns a user-configured password prompt, you can run through a list of common usernames and harvest all relevant password prompts, then visually browse the list looking for easily guessed ones. to the password.

Grep Payloads – These settings can be used to extract whether the response message contains the Payload value. For example, if you want to verify whether the reflective XSS script is successful, you can set this item. When this is set, a new column will be added in the response result list based on the number of Payload groups to display matching results.
You can sort and search the result set by clicking on the column title.

The setting items are similar to the previous one. It should be noted that Match against pre-URL-encoded payloads . If you configure URL-encode payloads when requesting a message, this means matching the Payload value before encoding, not after transcoding. value.

Redirections – These settings are mainly used to control how Burp handles redirections when executing attacks. In actual use, redirections must be followed to achieve the purpose of your attack.

For example, in a password guessing attack, the result of each attempt may be that a wrong password will redirect the response to an error message prompt page, and if the password is correct, it will redirect to the home page of the user center. But setting up redirects may also encounter other problems.

For example, in some cases, it may be necessary for the application to store the results of the initial request in your session and retrieve this value when providing the redirect response. Only use a single thread attack when redirecting. You may also encounter that when you set up a redirect, the application response will be redirected to the logout page. At this time, following the redirect may cause your session to be terminated. Because the setting options are basically the same as the redirection settings of other modules, they will not be repeated here.

Intruder attack and result analysis

There are usually two ways to launch an attack. One is that you set Target, Positions, Payloads and Options in Burp Intruder, and then click [Start attack] to start the attack; the other is that you open a previously saved pre-attack file, and then click [Start attack] to start the attack. No matter which method of attack is launched, Burp will pop up the attack result interface. During the attack, you can also modify the attack configuration or perform other operations. The attack result interface is shown in the figure below:

As we can see from the picture above, its interface mainly consists of four parts: menu area, filter, Payload execution result message recording area, and request/response message area.

• The menu area includes Attack menu, Save menu, and Columns menu. The Attack menu is mainly used to control attack behavior. You can pause the attack ( pause ), resume the attack ( resume ), and attack again ( repeat ). The Save menu is mainly used to save various data of the attack. Attack saves a copy of the current attack, and you can attack again from this file next time. The Results table saves the result list of the attack, which is equivalent to the data in the Payload execution result message recording area in the figure. Of course You can select rows and columns to save and export only the data you need; Server responses save all server response messages; Attack configuration saves the current attack configuration information. The Columns menu is mainly used to control the display columns of the message recording area. If a column is selected, it will be displayed in the Payload execution result message record area, otherwise it will not be displayed.
• Filter – You can filter by query conditions, server response status code, and information annotated in the Payload execution result message record area.
• The Payload execution result message recording area, also known as the Results Table, records all the information requested and responded when the Payload is executed. The columns it contains are: Request sequence – displays the sequence number of the request. If the record is not modified, it is configured. Requesting the message motherboard will be logged first. Payload location – Payload value will be recorded in sniper mode – if there are multiple Payloads, there will be multiple columns HTTP status code – server response status code Request time – the time to execute the attack Response time – start receiving the response Time in milliseconds. Response Completion Time – The time when the response is completed, in milliseconds. Network error – whether a network problem occurs when the payload is executed. Timeout – whether a network timeout occurs while waiting for a response. Length – the length of the response message . Cookie – any cookie information. Grep – if Grep matching and Grep extraction are set. , Grep Payload, there will be multiple columns showing matching information redirection – if redirection is configured, comments – the comment information of the message record will be displayed
• Request/response message area – refer to the relevant description in the Proxy chapter.

In the analysis of the attack results, you can reorder the contents of the table by clicking on any column header (clicking on the header cycles through ascending sorted, descending sorted and unsorted). A key part of effectively interpreting the results of an attack is locating valid or successful server responses and determining which requests generated these. Valid responses can usually differ by at least one of the following: 1. Different HTTP status codes 2. Responses of different lengths 3. The presence or absence of certain expressions 4. The occurrence of errors or timeouts 5. Used to receive or Differences in Completion Response Times For example, during a URL path scan, a request for a resource that does not exist may return a “404 Not Found” response, or the correct URL may return a “200 OK” response. Or in a password guessing attack, a failed login attempt might generate a “200 OK” response containing the “Login Failed” keyword, while a successful login might generate a “302 Object Moved” response, or a different “200 OK” “Response page.

Each penetration tester may analyze Burp Intruder attack results differently, mainly due to differences in personal level and experience. In actual combat, only by slowly trying and accumulating can you quickly analyze the attack results to obtain the important information you care about.

Burp Suite Target, a pivotal component in the arsenal of every hacker and security professional!

Burp Suite Target is a module within the Burp Suite toolset specifically designed for web application security testing and analysis. It serves as the focal point for targeting and assessing the security posture of web applications.

Key features of Burp Suite Target include:

• Target Definition: Burp Suite Target allows users to define and configure the target web application they wish to assess. This includes specifying the URL, scope, and any authentication parameters required to access the application.
• Site Mapping: The tool enables users to comprehensively map out the structure and functionality of the target web application. This includes identifying all accessible pages, directories, parameters, and endpoints.
• Vulnerability Detection: Burp Suite Target includes built-in vulnerability detection capabilities, allowing users to automatically scan the target application for common security flaws such as SQL injection, cross-site scripting (XSS), and more.
• Customized Testing: Users can customize their testing approach within Burp Suite Target, tailoring scans and assessments to focus on specific areas of interest or to meet compliance requirements.
• Reporting: The module provides robust reporting features, allowing users to generate detailed reports of their findings, including identified vulnerabilities, recommended remediation steps, and overall risk assessment.

How to use Burp Suite Target

The Burp Target component mainly consists of three parts: site map, target domain, and Target tool. They help penetration testers better understand the overall status of the target application, which target domains are involved in the current work, and analyze possible attack surfaces and other information. Below Let’s take a look at the three components of Burp Target respectively.

The main contents of this chapter are:

• Target domain settings Target Scope
• Site MapSite Map
• Using Target Tools

Burp Suite Target domain settings Target Scope

The definition of scope in Target Scope is relatively broad. Generally speaking, when we perform a penetration test on a product, we can restrict intercepted content by domain name or host name.

The domain name or host name here is what we call the scope; if we If you want to make the restriction more fine-grained, for example, if you only want to intercept all requests under the login directory, we can also set it here. In this case, the scope is the directory. Generally speaking, Target Scope is mainly used in the following scenarios:

• Limit results displayed in sitemap and proxy history
• Tell Burp Proxy which requests to intercept
• What content does Burp Spider crawl?
• Burp Scanner automatically scans which scopes for security vulnerabilities
• Specifying URLs in Burp Intruder and Burp Repeater

Through Target Scope, we can easily control Burp’s interception range and operation objects, and reduce invalid noise. Target Scope’s settings mainly include two parts: allow rules and remove rules.

The allow rules are as the name implies, that is, the operations included in this rule list are deemed to be allowed and valid. If this rule is used for interception, the request message matching the inclusion rule list will be intercepted; otherwise, the request message matching the removal list will not be intercepted.

As we can see from the Add Rule dialog box in the above figure, the rules mainly consist of four parts: protocol, domain name or IP address, port, and file name. This means that we can add the following parameters from the protocol, domain name or IP address, port, and file name. There are 4 dimensions to control which messages appear in the rule list or are allowed or excluded.

When we set up the Target Scope (all are allowed by default), use Burp Proxy for proxy interception, and when browsing the application through the browser proxy in the penetration test, Burp will automatically record the browsing information, including detailed information about each request and response. , saved in the Target sitemap.

Burp Suite Target Site Map

The site map shown in the figure below is the result of the browser browsing history displayed in the site map during a penetration test.

From the figure, we can see that the left side of the Site Map is the accessed URL. According to the level and depth of the website, the tree shape shows the structure of the entire application system and the URLs associated with other domains,

The right side shows the accessed URL of a certain URL. Detailed list, which URLs were visited, and what the request and response content were, are all recorded in detail. Based on the tree structure on the left, we can select a branch to add to scope.

In addition to adding the Target Scope, from the above figure, we can also see that for the layering of the site map, you can fold and expand it for better analysis. Site structure.

Using Target Tools site comparison

The use of Target tools mainly includes the following parts:

• Obtain sitemap manually
• site comparison

When we obtain the sitemap manually, we need to follow the following steps:

• 1. Set up the browser proxy and Burp Proxy proxy and make them work properly.
• 2. Turn off the interception function of Burp Proxy.
• 3. Browse the web page manually.

At this time, Target will automatically record the site map information. One advantage of manually obtaining the site map is that we can independently control the access content according to our own needs and analysis, and the recorded information is more accurate. Compared with automatic crawling, it takes longer.

If the product system that needs penetration testing is a large system, the power and time required to operate the function points of the system in sequence will be very costly to the penetration tester. very big.

Site comparison is a tool that Burp provides to penetration testers for dynamic analysis of sites. We often use it when comparing account permissions. When we log in to the application system and use different accounts, the accounts themselves are given different permissions in the application system, so the functional modules, content, parameters, etc. that the accounts can access are not the same.

At this time, use site comparison, It can help penetration testers distinguish them very well. Generally speaking, there are three main scenarios:

1. The same account has different permissions and compares the difference in the results of two requests.
2. Two different accounts with different permissions, compare the differences in the results of the two requests.
3. Two different accounts have the same permissions and compare the differences in the results of the two requests.

Let’s take a look at how to compare sites.

First, we right-click on the function link that needs to be compared, find the menu of site comparison, and click the menu to enter the next step.

Since site comparison is performed between two site maps, we need to specify Site Map 1 and Site Map 2 respectively during the configuration process. Normally, Site Map 1 we default to the current session. As shown in the picture, click [Next].

At this time we will enter the Site Map 1 settings page. If we want to compare the entire site, we will choose the first item. If we only compare the functions we selected, we will choose the second item. As shown below, click [Next]. If we are comparing the entire site and do not want to load other domains, we can check to select only the current domain.

Next is the configuration of Site Map 2. We also have two methods for Site Map 2. The first is the Burp Suite site record we have saved before, and the second is to re-generate a request as Site Map 2. Here , we choose the second method.

If you selected the second method in the previous step, enter the request message setting interface. In this interface, we need to specify the number of concurrent threads for communication, the number of failed retries, and the pause time.

After setting up Site Map 1 and Site Map 2, you will enter the request message matching settings. In this interface, we can filter matching conditions by URL file path, HTTP request method, request parameters, request headers, and request body.

Set the request matching conditions, and then enter the response comparison setting interface. On this interface, we can set what content we specify that needs to be compared. From the figure below, we can see that there are mainly response headers, form fields, spaces, and MIME types. Click [Next].

If we were comparing the entire site before and chose to re-produce it as Site Map 2, you will be constantly prompted with the progress of data loading during the interface loading process. If there are few links involved in function requests, it will be very difficult. Quickly enter the comparison interface. As shown below.

From the picture above, we can see that the upper part of the site comparison interface is the filter (this filter is used the same as other filters, so I won’t go into details here), and the lower part is composed of left, middle and right blocks. The left is the requested link list, the middle is the message records of Site Map 1 and Site Map 2, and the right is the message details.

When we select a message record in Site Map 1, the corresponding record in Site Map 2 will be automatically selected by default. This is controlled by the [Synchronization Selection] checkbox in the upper right corner.

At the same time, in the message details area on the right, The difference in communication messages between Site Map 1 and Site Map 2 will be automatically displayed, including request messages and response messages. Differences will be marked with a background color.

Burp Suite target scan

we will delve into the basics and usage of Burp Suite target analysis and target scanning.

Target scanning basics

Target scanning is a feature in Burp Suite for automated testing of web applications. It automatically discovers vulnerabilities and security issues in web applications and generates reports for analysis.

In Burp Suite, target scanning includes the following main components:

• Target: The web application that the user wants to test.
• Target Scope: Defines the scope of the web application to be tested.
• Scan policy: Define the scan policy to use.
• Scan options: Includes advanced settings such as setting scan speed and excluding specific vulnerability types.

Define scan targets

Before using the target scanning function, we need to define the target to be scanned. In Burp Suite, we can define scan targets through the following steps:

1. In the “Target” tab of the main interface of Burp Suite, click the “Site map” button.
2. Right-click on the target you want to scan and select the “Add to scope” option. This will add the target to the target scope.
3. In the “Target” tab, click the “Engagement tools” button.
4. In the Engagement tools tab, select the Scan tab.
5. Click the “Add” button, select the target to scan, and select the scanning policy to use.
6. Click the “Start scan” button to start scanning the target.

Through the above steps, we can add targets to the target scope and use scanning policies to automatically discover vulnerabilities and security issues in web applications.

Define scan range

After defining the scan target, we need to define the scan scope. The scan scope defines the scope and depth of the web application to be tested. In Burp Suite, we can define the scan scope in the following ways:

• Manually add: Manually add the URL or IP address to be tested.
• Automatic addition: Automatically add URLs or IP addresses to test by using Burp Suite’s “Spider” tool.
• Import from file: Import the URL or IP address to be tested from a file.

After defining the scanning scope, we can use scanning strategies to automatically discover vulnerabilities and security issues in web applications.

Define scan strategy

Scan policies define the testing techniques and vulnerability types to be used. In Burp Suite, we can choose from the following scanning strategies:

• Active Scanning: Use Burp Suite’s active scanning feature to discover vulnerabilities and security issues in web applications.
• Driven Scanning: Use Burp Suite’s driven scanning feature to discover vulnerabilities and security issues in web applications.
• Manual Testing: Manually test web applications for vulnerabilities and security issues.

After selecting a scan strategy, we can use scan options to further define our testing needs.

Define scan options

Scan options include advanced settings such as setting scan speed and excluding specific vulnerability types. In Burp Suite, we can define scan options by following these steps:

• In the “Target” tab of the main interface of Burp Suite, click the “Engagement tools” button.
• In the Engagement tools tab, select the Scan tab.
• In the Scan tab, select the scan policy to use.
• Click the “Settings” button to enter the scanning options interface.

In the scan options interface, we can set the scan speed, exclude specific vulnerability types and other advanced settings.

In this article, we discuss the basics and usage of target scanning for Burp Suite target analysis. We learned how to define scan targets, scan scope, scan strategy, and scan options.

By using Burp Suite target analysis and target scanning, we can automatically discover vulnerabilities and security issues in web applications and generate reports for analysis.