Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum will be discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Centre. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTRE DISCORD

Create new post

Intruder payload generator sequencing and tracking http responses

Joris | Last updated: Sep 12, 2024 04:22PM UTC

My payload generator needs to know the response from the previous payload that was sent. Http request/responses have message ids to correlate, but I can't find a way to reliably track the payload I generated in the request/response. I could just assume the last payload and the last request correlate, but that's not exactly very robust as you can actually run two intruder attacks at once. Is there anything in the payload generator extension API I can use to tag the payload or grab the message id or something? I've also noticed intruder grabs new payloads even before the previous responses are in (it seems to run 2-3 requests ahead). Is there a way to control this behavior?

Hannah, PortSwigger Agent | Last updated: Sep 13, 2024 02:55PM UTC

Hi Intruder attacks typically run with multiple concurrent requests, which is probably why you're finding it's grabbing multiple new payloads. If you drop your resource pool down to one concurrent request, does that improve the behavior around this? Could you explain a bit more about the functionality you are looking for with sending follow up requests based on the response? If you prefer, you can drop us an email at support@portswigger.net.

Joris | Last updated: Sep 16, 2024 05:20PM UTC

Hi Hannah! Well the payload generator is the logic that decides to end the intruder sequences. But what if that decision is based on the responses? In our case, our AI red teaming tool attempts to jailbreak AI. As such, we evaluate the response to our payload to check if the AI is acknowledging the jailbreak. Once it does, we end the intruder attack. This works well, except that a few new payloads are already generated by the time our response scoring has determined a response contains an acknowledgement. And yes, setting the resource pool to 1 works. But I'm still interested to see if there's a way in the payload generator to know either the intruder attack "instance" or the message id of the upcoming request so my extension can track it.

Hannah, PortSwigger Agent | Last updated: Sep 18, 2024 04:24PM UTC

We have an existing feature request to add an optional "stop" condition for when specific data is contained within the response - this sounds like it would be useful for you in this case so I have added your +1 to this feature request. With regards to tracking request/responses from the payload generator, I don't think there's a particularly good way to go about this. As you have access to the value that you've built including the payload to send, you could try registering an HttpHandler and matching outgoing requests to your GeneratedPayload request. However, I believe that any payload processing rules are applied after you've provided the GeneratedPayload, so this could interfere with matching outgoing requests in your HttpHandler. If you were to run more than one attack at a time, you may potentially have more than one match for your payload with no way to associate which task has triggered the match.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.