Hello world, welcome to haxez where today we’re looking at Hack This Site Realistic Web Mission Level 8. This mission requires us to perform an SQL injection to obtain the username of our victim. Once we have the username, we need to register an account and manipulate the cookies in order to transfer ten million dollars from our victim’s account to our client’s account. After that, we need to hide all evidence of our nefarious actions by deleting the log files. If you haven’t seen my other posts on the realistic series you can do so here: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, and Part 7.
![Realistic 8 United Banks of America](https://haxez.org/wp-content/uploads/2025/01/0zxogWiOPlyx_7qvR.png)
Realistic 8 Introduction
We’ve received a message from DarkOneWithANeed. The message explains that an entrepreneur by the name of Gary Hunter has deposited ten million dollars into his United Banks Of America bank account. The purpose of the deposit is so that he can donate it to a campaign. The campaign’s goal is to hunt down and lock up hackers. The client would like us to break in and steal this money.
![Realistic 8 Message From DarkOneWithANeed](https://haxez.org/wp-content/uploads/2025/01/0x7LX7PThrLnoJP-z.png)
Exploring The Realistic 8 Web Application
First things first, let’s head over to the application and see what we’re dealing with. At first glance, the web application appears to be fairly basic. It has a number of pages including home, login, register, help, and user info. If we look back at the message, the first challenge is to find the account of Gary Hunter. Fortunately, there appears to be a User Info page.
![Realistic 8 Web Application — United Banks of America](https://haxez.org/wp-content/uploads/2025/01/0zXVERr9H0q8LcVf4.png)
Realistic 8 Web Application User Info SQL Injection
The user info page allows us to search for users. However, if we search for the name Gary we get a single user returned. We can try searching for the letter A in hopes that it would return all users with an A in their name but that doesn’t work. If we input a single quotation mark we get an SQL error explaining that there was a problem getting username information from table ‘users’. This indicates, that the application is vulnerable to SQL injection.
![Realistic 8 Web Application — User Info SQL Error](https://haxez.org/wp-content/uploads/2025/01/0vVIlH6MmY9pJ8oJH.png)
If we use the following payload in the search box we should get a list of users. The reason this works is that we’re escaping the syntax and adding our own and commenting out the rest. Our syntax is telling the SQL server to return user ‘a’ or anything that’s true (exists).
' or 1=1 --
![Web Application — SQL Injection](https://haxez.org/wp-content/uploads/2025/01/0E-Yn8Fsv0HtxTHw0.png)
Once we submit the payload, we should get a list of users returned. If we hit ctrl f on our keyboard we can search for Gary. The first result should be our victim Gary Hunter. Copy and paste his name and the –$$$$$ — value into your notes because we will need it later.
![SQL Injection — Results](https://haxez.org/wp-content/uploads/2025/01/0dekBnYX4nnGRTGGc.png)
Move Money Cookie Manipulation
Now that we have our victim’s username, we need to transfer the ten million dollars from their account to our client’s account. In order to do this, we need to register our own account and see what functionality we have. I’ve registered the username haxez.
![Web Application — Register Account](https://haxez.org/wp-content/uploads/2025/01/0conyGizfVUFUqbf4.png)
Once the account is created, log in. You should see that you have your account information and two options. Clear files in a personal folder and move money to a different account. Unfortunately, as in real life, we have no money in our bank account. However, perhaps there is a way for us to deceive the web application into think we’re Gary Hunter. If we pre-populate the move money option and load up our favorite web application penetration testing tool, Burp Suite. We can intercept the request before it is sent to the server.
![Web Application — Move Money](https://haxez.org/wp-content/uploads/2025/01/0G4I_CSsJUAXepsp6.png)
Once you’ve populated the “Move Money” parameters, ensure Burp Suite intercept is on and click the Move Money button. You should see a window like the one below (depending on your theme, dark mode rules). If we analyze the request, you can see that the request is posting to movemoney.php. The contents of the request are two parameters, TO=dropCash
and AMOUNT=1000000000
. However, the value ten million may look odd because it is being URL encoded. You should also see that there are a number of cookies. The cookies we want to manipulate are “accountUsername
” and “accountPassword"
. Fortunately, Burp allows us to modify these values directly before submitting them. Edit the cookies and replace them with the values we obtained from the SQL injection
(accountUsername=GaryWilliamHunter; accountPassword=-- $$$$$ --;
).
Forward the request.
![Request — Interception and Manipulation](https://haxez.org/wp-content/uploads/2025/01/0MhZEQetKnjqUXLTB.png)
Web Application Clear Files Hack
Now that we have committed the crime of the century, we need to cover our tracks. The client’s email advises us that the logs are kept in a directory called logFiles. After transferring the funds, you will be logged out of the application. Log back into the application and turn on Burp intercept again. Click the “Clear files in personal folder” button. Jump back to Burp and you should see the request. At the bottom of the headers, you will see the parameter dir=<usernameSQLFiles>
. Change this value to logFiles and forward the request.
![Request — Modification](https://haxez.org/wp-content/uploads/2025/01/0UQzbWU49groZlSVf.png)
After that, you can head back to your browser and you should see that you have successfully completed the mission.
![Congratulations](https://haxez.org/wp-content/uploads/2025/01/0tBXjTriw41XYsJB1.png)
Conclusion
This was a fun challenge that allowed us to don the hood of the vigilante hacker once again. While the application was outdated, it demonstrated how poor design choices can lead to weaknesses in security. The SQL injection was possible because the application wasn’t using prepared statements. This could have been mitigated with something similar to the following.
$stmt = $conn->prepare"SELECT FROM Users (Username, Description) VALUES (?)"0;$stmt->bind_param("s", $Username, $Description);
The cookie manipulation that was used to transfer the funds was a fun technique to use. It’s an example of why session tokens and Anti-Cross-Site Request Forgery tokens are important. By having unique non-descript cookies, and server-side checks to verify those cookies, you ensure that malicious threat actors can’t hijack other user’s sessions or in this case, impersonating a user and submitting data.
The directory manipulation on the clear log files form was another great example of why anything being transmitted from the user’s browser shouldn’t be trusted. The data could be manipulated and have unexpected consequences. This could be mitigated by using a session token to reference properties stored in a server-side cache. It could also be mitigated by validating the values before processing them.
Anyway, I hope you enjoyed this post. Come back next time where we will look at realistic 9.