TryHackMe Hacker Holidays 2026 — Towel on the Sunbed Writeup
Written By Aryan Giri
Room: Towel on the Sunbed
Category: Web
Difficulty: Medium
Room URL: https://tryhackme.com/room/hh-towelonthesunbed-61271709
Scenario
Ponzi discovered a crypto rewards application running as part of the hotel's wellness portal. Guests can claim 50 reward points once every 24 hours, and reaching 150 points unlocks the exclusive Whale Vault.
Waiting three days would certainly work—but this room is about finding a flaw in the application's business logic.
Learning Objectives
- Analyze application workflows using Burp Suite
- Identify business logic vulnerabilities
- Exploit a race condition
- Abuse concurrent requests
- Understand why server-side synchronization matters
Initial Enumeration
Before interacting with the application, ensure Burp Suite is configured as your browser proxy so every request can be inspected.
Visiting the application redirects to the login page.
A registration option is available, so create a test account.
Example credentials:
Username: tester
Password: tester
After logging in, the dashboard becomes available.
Understanding the Reward System
The dashboard contains a Claim Reward button.
Each successful claim awards:
- 50 Points
- Only once every 24 hours
The application also contains a Vault section.
The vault requires:
150 Points
to unlock.
After claiming once, the balance becomes 50 points.
At this point there are two obvious possibilities:
- Wait three days
- Find a way to bypass the 24-hour limitation
Since this is a Hacker Holidays room, the second option is clearly the intended path.
Exploring the Application
Out of curiosity, inspect the site's endpoints using Burp Suite.
The sitemap reveals several API endpoints.
Although /api initially looks interesting, nothing here is directly vulnerable by itself.
The vulnerability lies in how the application processes reward claims, not in hidden endpoints.
Exploiting the Race Condition
The challenge revolves around abusing multiple reward requests arriving at the server simultaneously.
To avoid cooldowns from the first account, log out and create a fresh account.
Example:
Username: tester2
Password: tester2
Capture the Request
Enable Burp Intercept.
Proxy
↓
Intercept
↓
Intercept is ON
Return to the application and press Claim Reward.
Burp intercepts the request.
Right-click the intercepted request and choose:
Send to Repeater
Do not forward the request yet.
Creating a Request Group
Inside Repeater:
Right-click the request tab.
Select:
Add tab to group
Create a new group using the default settings.
Now duplicate the request.
Duplicate Tab
Instead of creating only three requests, increase the number to 30 duplicated tabs.
Why 30 Requests?
At first glance, simple math suggests:
50 × 3 = 150
So three simultaneous requests should be enough.
Interestingly, they aren't.
Testing with only three concurrent requests usually results in only 100 points.
This happens because concurrent processing depends on the server's internal implementation.
Without access to the source code, we cannot know exactly how requests are scheduled or when balance updates occur.
Sending a much larger burst significantly increases the likelihood that multiple requests will pass validation before the balance is updated.
Sending Requests in Parallel
Do not press the normal Send button.
Instead, click the small arrow beside Send.
Choose:
Send in parallel
Execute every request simultaneously.
Burp sends all duplicated requests at nearly the same time.
If the application lacks proper synchronization, several requests successfully award points before the server realizes the reward has already been claimed.
Verify the Result
Return to the browser.
Disable Burp/FoxyProxy so traffic reaches the application normally.
Refresh the dashboard.
You should now have well over 150 points.
Open the Whale Vault.
The application reveals the flag.
The flag is intentionally hidden here to comply with TryHackMe rules.
Root Cause
The reward endpoint likely performs operations in roughly this order:
- Check whether today's reward has already been claimed.
- Award 50 points.
- Update the database.
When multiple requests arrive simultaneously, several of them complete the validation step before any request updates the user's reward status.
As a result, multiple reward claims are accepted during the same time window.
This is a classic Race Condition combined with a Business Logic Vulnerability.
Real-World Impact
Although this lab awards fictional crypto points, similar vulnerabilities appear in production applications.
Examples include:
- Reward point abuse
- Loyalty programs
- Coupon redemption
- Promotional credits
- Gift card balance manipulation
- Referral bonuses
- Cryptocurrency faucets
- Banking reward systems
Poor request synchronization can lead to significant financial losses if attackers automate concurrent requests.
Key Takeaways
- Business logic vulnerabilities often exist even when authentication and authorization are correctly implemented.
- Race conditions occur when multiple requests interact with shared data simultaneously.
- Burp Suite's Send in Parallel feature is extremely useful for testing concurrency issues.
- Never assume "once every 24 hours" is securely enforced until the backend has been tested.
- Server-side locking, atomic database operations, or transactional updates are essential to prevent this class of vulnerability.
Conclusion
This room demonstrates that exploiting web applications isn't always about SQL injection or remote code execution.
Sometimes the most effective attack is simply sending perfectly valid requests at the same time.
Understanding application logic, request timing, and backend behavior is often enough to bypass restrictions that appear secure from the user interface.