All PostsWriteups & Video Tutorials

Advent of Cyber 2025 Day 20 Walkthrough Race Conditions – Toy to The World

Task 1 Introduction

Click here to access the Advent of Cyber 2025 Day 20 Walkthrough Race Conditions – Toy to The World Room Lab

The Story Advent of Cyber 2025 Day 20 Walkthrough Race Conditions – Toy to The World

Task banner for day 20

The Best Festival Company (TBFC) has launched its limited-edition SleighToy, with only ten pieces available at midnight. Within seconds, thousands rushed to buy one, but something strange happened. More than ten lucky customers received confirmation emails stating that their orders were successful. Confusion spread fast. How could everyone have bought the “last” toy? McSkidy was called in to investigate.  

She quickly noticed that multiple buyers purchased at the exact moment, slipping through the system’s timing flaw. Sir Carrotbane’s mischievous Bandit Bunnies had found a way to exploit this chaos, flooding the checkout with rapid clicks. By morning, TBFC faced angry shoppers, missing stock, and a mystery that revealed just how dangerous a few milliseconds could be during the holiday rush.

Learning Objectives

  • Understand what race conditions are and how they can affect web applications.
  • Learn how to identify and exploit race conditions in web requests.
  • How concurrent requests can manipulate stock or transaction values.
  • Explore simple mitigation techniques to prevent race condition vulnerabilities.

Connecting to the Machine

Before moving forward, review the questions on the connection card below:

Connection card.

Start your target VM by clicking the Start Machine button below. The machine will need about 2 minutes to fully boot. Additionally, start your AttackBox by clicking the Start AttackBox button below. The AttackBox will start in split view. In case you can not see it, click the Show Split View button at the top of the page. Once the machine is up and running, you can access the application by visiting http://MACHINE_IP in the browser of your AttackBox.

Set up your virtual environment

To successfully complete this room, you’ll need to set up your virtual environment. This involves starting both your AttackBox (if you’re not using your VPN) and Target Machines, ensuring you’re equipped with the necessary tools and access to tackle the challenges ahead.

blank

Answer the questions below

I can successfully connect to the machine.

No answer needed

Task 2 Race Condition

A race condition happens when two or more actions occur at the same time, and the system’s outcome bunny character showing car racing. depends on the order in which they finish. In web applications, this often happens when multiple users or automated requests simultaneously access or modify shared resources, such as inventory or account balances. If proper synchronisation isn’t in place, this can lead to unexpected results, such as duplicate transactions, oversold items, or unauthorised data changes.

Types of Race Conditions

Generally, race condition attacks can be divided into three categories:

  • Time-of-Check to Time-of-Use (TOCTOU): A TOCTOU race condition happens when a program checks something first and uses it later, but the data changes in between. This means what was true at the time of the check might no longer be true when the action happens. It’s like checking if a toy is in stock, and by the time you click “Buy” someone else has already bought it. For example, two users buy the same “last item” at the same time because the stock was checked before it was updated.
  • Shared resource: This occurs when multiple users or systems try to change the same data simultaneously without proper control. Since both updates happen together, the final result depends on which one finishes last, creating confusion. Think of two cashiers updating the same inventory spreadsheet at once, and one overwrites the other’s work.
  • Atomicity violation: An atomic operation should happen all at once, either fully done or not at all. When parts of a process run separately, another request can sneak in between and cause inconsistent results. It’s like paying for an item, but before the system confirms it, someone else changes the price. For example, a payment is recorded, but the order confirmation fails because another request interrupts the process.

Time for Some Action

Now that we understand the basic concepts, let’s take the example of the TBFC shopping cart app and exploit the race condition.

Configuring the Environment

First, we will configure Firefox to route traffic through Burp Suite. On the AttackBox, open Firefox, click the FoxyProxy icon (1) and select the Burp profile (2) so all browser requests are sent to Burp, as shown below:

Firefox window to select Burp profile.

Next, click on the Burp Suite icon on the Desktop to launch the application. 

Ubuntu desktop screen with Burp icon.

You will see an introductory screen; choose Temporary project in memory and click Next.

Introductory screen in Burp Suite.

On the configuration screen, click Start Burp to start the application.

Startup screen in Burp Suite.

Once the application is started, you will see the following screen, where we will use the Proxy and Repeater option to exploit the race condition.

Welcome screen in Burp Suite.

 

Before proceeding, ensure that you turn off “Intercept” in Burp Suite. Open the Proxy tab and check the Intercept sub-tab; If the button says “Intercept on“, click it so it changes to “Intercept off“. This step ensures that Burp Suite no longer holds your browser requests and allows them to pass through normally.

Turn off intercept option in Burp Suite.

Making a Legitimate Request

Now that the environment is configured, make a normal request. Open Firefox, visit the webapp at http://MACHINE_IP, and you will see the following login page:

TBFC login page.

On the site’s login panel, enter the credentials, username: attacker and password: attacker@123. After logging in, you’ll arrive at the main dashboard, which shows the limited-edition SleighToy with only 10 units available.

TBFC welcome page.

To make a legitimate purchase, click Add to Cart for the SleighToy and then click Checkout to go to the checkout page.

TBFC inventory page.

On the checkout page, click Confirm & Pay to complete the purchase. You should see a success message confirming the order, as shown below:

TBFC checkout page.

Exploiting the Race Condition

Now that we have made a legitimate request, navigate back to Burp Suite and click on  Proxy > HTTP history and find the POST request to the /process_checkout endpoint created by our legitimate checkout request. Right-click that entry and choose Send to Repeater, which will copy the exact HTTP request (headers, cookies, body) into Burp’s Repeater tool as shown below:

Sending Burp Suite with multiple requests.

Next, switch to the Repeater tab and confirm the request appears there, right-click on the first tab, select Add tab to group, and click on Create tab group.

Burp Suite to create tab group.

Enter a name for the tab group, such as cart, and click Create, which will create a tab group named cart.

Create Tab Group screen in Burp Suite.

Then, right-click the request tab and select Duplicate tab. When prompted, enter the number of copies you want (for example, 15). You’ll now have that many identical request tabs inside the cart group.

Duplicate requests in Burp Suite.

Next, use the Repeater toolbar Send dropdown menu and select Send group in parallel (last-byte sync), which launches all copies at once and waits for the final byte from each response, maximising the timing overlap to trigger race conditions.

Send Parallel requests in Burp Suite.

Once this is done, click Send group (parallel); this will launch all 15 requests to the server simultaneously. The server will attempt to handle them simultaneously, which will cause the timing bug to appear (due to multiple orders being processed at once).

Response after sending successful requests.

Finally, visit the web app, and you will see multiple confirmed orders and the SleighToy stock reduced (possibly going negative). 

Negative stocks and flag value.

Mitigation

The attacker logged in and made a normal purchase of the limited SleighToy. Using Burp Suite, he captured the checkout request and sent it multiple times in parallel. Because the app didn’t handle simultaneous checkouts correctly, each request succeeded before the stock could update. This allowed the attacker to buy more toys than available, resulting in a race condition and pushing the stock into negative values. Here are a few mitigation measures to avoid the vulnerability:

  • Use atomic database transactionsso stock deduction and order creation execute as a single, consistent operation.
  • Perform a final stock validation right before committing the transaction to prevent overselling.
  • Implement idempotency keys for checkout requests to ensure duplicates aren’t processed multiple times.
  • Apply rate limiting or concurrency controls to block rapid, repeated checkout attempts from the same user or session.

Answer the questions below

What is the flag value once the stocks are negative for SleighToy Limited Edition?

THM{WINNER_OF_R@CE007}

Repeat the same steps as were done for ordering the SleighToy Limited Edition. What is the flag value once the stocks are negative for Bunny Plush (Blue)?

THM{WINNER_OF_BUNNY_R@CE}

Feel free to check out the Race Conditions room if you enjoyed this task.

No answer needed

Completion Message – Advent of Cyber 2025 Day 20

Congratulations! 🎉 You’ve successfully completed Advent of Cyber 2025 Day 20 Walkthrough – Race Conditions: Toy to The World.
In this lab, you learned how race condition vulnerabilities occur in real-world web applications and how attackers can exploit timing flaws using concurrent requests. By leveraging Burp Suite Repeater and sending parallel checkout requests, you were able to manipulate inventory logic, force negative stock values, and retrieve both challenge flags.

This task highlighted the critical importance of atomic transactions, concurrency control, and proper validation in high-traffic applications especially during peak events like limited-edition product launches. Excellent work sharpening your web exploitation and defensive security knowledge! 🚀

Related Resources

FAQs – Advent of Cyber 2025 Day 20 Walkthrough

1. What is a race condition?

A race condition occurs when two or more processes access and modify shared resources simultaneously, and the final outcome depends on the order in which the operations complete. In web applications, this can lead to issues like overselling products, duplicate transactions, or inconsistent data.

2. What are the main types of race conditions?

1. Time-of-Check to Time-of-Use (TOCTOU): When a system checks a condition and then performs an action, but the data changes between these steps.
2. Shared resource race: When multiple users or processes update the same resource simultaneously without proper synchronization.
3. Atomicity violation: When an operation meant to be executed as a single unit is interrupted, allowing another request to interfere.

3. How was the race condition exploited in Day 20?

A legitimate purchase request for the limited-edition SleighToy was captured using Burp Suite.
The request was duplicated multiple times and sent in parallel using Burp Suite Repeater.
The server attempted to process all requests simultaneously, bypassing stock checks, causing negative inventory, and generating the flags.

4. What are the flags for Day 20?

SleighToy Limited Edition: THM{WINNER_OF_R@CE007}
Bunny Plush (Blue): THM{WINNER_OF_BUNNY_R@CE}

5. How can race conditions be prevented?

Use atomic database transactions for critical operations like stock deduction and order creation.
Validate inventory immediately before committing the transaction.
Implement idempotency keys for critical requests to prevent duplicate processing.
Apply rate limiting and concurrency controls to block rapid repeated requests.

6. Why are race conditions important to understand in cybersecurity?

Race conditions can be exploited to bypass application logic, steal goods, or manipulate financial transactions. Understanding them helps developers secure applications and helps ethical hackers identify vulnerabilities in penetration testing.

7. Which tools were used in this walkthrough?

Burp Suite: Proxy, HTTP history, Repeater (to capture and replay requests)
Firefox: Configured with FoxyProxy to route traffic through Burp Suite
AttackBox & Target VM: Virtual environment for practicing the exploit

Mehmood Ali

I am a Cybersecurity Consultant with over 8+ years of experience in SOC analyst, digital forensics, cloud security, network security, and incident response. With 20+ international certifications, I have successfully designed secure systems, led vulnerability assessments, and delivered key security projects. I am skilled at improving incident response times, mitigating threats, and ensuring compliance with ISO 27001 standards.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button