version: "1.0.0" name: vrt-enhance description: how to improve victim response theft (VRT) on targets that are already confirmed vulnerable disabled: true

Victim Response Theft

Victim response theft occurs when you smuggle a complete, standalone request that generates its own response.

Mechanism

Front-end servers match responses to requests in order. When you smuggle a complete request:

• Front-end sees 1 request, expects 1 response
• Back-end processes 2 requests, sends 2 responses
• The extra response remains queued on the connection

The next legitimate user's request receives your smuggled request's response. Their actual response queues for the following user, creating a cascade.

Distinction from Prefix Smuggling ┌──────────────────────────────────┬─────────────────────────────────┐ │ Prefix smuggling │ Victim response theft │ ├──────────────────────────────────┼─────────────────────────────────┤ │ Incomplete smuggled request │ Complete smuggled request │ ├──────────────────────────────────┼─────────────────────────────────┤ │ Victim's request completes yours │ Victim's request is independent │ ├──────────────────────────────────┼─────────────────────────────────┤ │ Targeted single-victim impact │ Cascading multi-victim impact │ └──────────────────────────────────┴─────────────────────────────────┘

If you see a highly anomalous response that may have been intended for another user at any point, save it to the organizer.

Improving victim response theft

1. First, use the vrt-validated.py template to replicate the issue.
2. Observe how many requests it takes to sucessfully trigger the issue
3. Explore techniques to reduce the number of requests required, *by changing the smuggled request*. You can use the turbo simulator MCP to run the micro-crawl.py example script (turbo://examples/micro-crawl) to find endpoints.
4. If you find a technique that makes a consistent difference, that's success. Verify it multiple times to be sure.

Advice

On some servers, VRT is very easy to trigger using tens of request per second. On others, it can only be triggered by sending thousands of requests per second and even then it's rare, as though it requires triggering a race condition.

My hypothesis is that many front-end servers often "over-read" when reading in the first response, leading to them getting some data from the second response (to the smuggled requesting), triggering some kind of error which breaks the attack.

Consider possible causes of this race condition, and attempt workarounds to increase the size of the race window.

Run hypothesis_report.py to get a dynamically generated list of the best proven techniques.