The fantasy cricket platform that was already hijacked

Back in 2019 I spent an evening poking at a real-money fantasy cricket platform, the kind where you build a team, pay an entry fee and win cash. I was only going to try the app once. Instead I walked straight through the front door, then found the house had already been burgled.

The platform is defunct now, so I am publishing this with the company name, its infrastructure and every credential and personal record redacted. This is about the chain of mistakes, not the people behind it.

The short version

What was broken:

1. OTP generated on the client. Login verification could be bypassed without ever receiving a real code.
2. Unrestricted file upload. The profile-photo uploader accepted and executed arbitrary PHP.
3. Directory listing left enabled on the upload path.
4. Hardcoded database credentials sitting in a world-reachable PHP file.

What that chain let an attacker do:

• Take full control of the server, the website and the app, and ship new builds.
• Read and alter every user's data.
• Impersonate the platform to its users.

How it went

I just wanted to try the app once. Before installing it I opened the website and noticed you could play from the browser too, so I started signing up. That is where it got interesting.

The moment I requested an OTP it dropped me on a "Verify OTP" screen, and when I typed a wrong code the rejection came back instantly, with no round trip that felt like a server checking anything. Dev tools confirmed it: the OTP was being generated on the client, and every verification request carried the expected OTP along with it. So I entered a random phone number, read the OTP straight out of the request, and logged in.

Once that one assumption fell, I started wondering what else was soft. During recon I could tell the backend was PHP. The profile section had a photo uploader, so I uploaded an image, inspected the rendered <img> to find where it landed, and checked whether directory listing was disabled on that folder. It was not.

Next I uploaded a simple PHP script. There was no real validation on the upload, and the file was:

1. moved into a public directory,
2. whose directory listing was enabled,
3. on the same server as the main application.

So visiting that file executed it. From there I could read directories, and I found database connection code with the credentials hardcoded in plain text. At that point it was effectively full access to the system.

The part I did not expect

Later the same day I went back to upload a fresh script, and next to mine I noticed a PHP file I had not put there. I opened it, and it was a full-blown web shell, far more capable than a basic command runner.

I used its own file browser to check when the shell was created. It had been sitting there for several days before I ever showed up. Someone, most likely a script kiddie, had planted it and was coming back whenever they liked. I could see database backups being pulled. Using the hardcoded credentials, the same shell could open the database directly, including the admin accounts (names and passwords redacted here):

I watched for a day or two, then contacted the team. They were technical, but they struggled to grasp how bad it was or how to begin fixing it.

The disclosure

I wrote up the issues and the fixes I thought mattered most. The core of that report:

1. Disable directory listing.
2. Handle every sensitive API call server-side. The SMS trigger, for instance, exposed the provider key to the client, so anyone could send messages. Lock down CORS instead of trusting the browser.
3. Never store passwords unhashed.
4. Never hardcode admin or infrastructure credentials in server-side source.
5. The app was wide open to SQL injection throughout. Nothing was parameterized.
6. Guard against XSS on the client.
7. Take file uploads seriously. Extensions can be spoofed, so verify the actual file type and lean on well-tested libraries rather than hand-rolled checks.
8. Never generate security-sensitive values on the client. The OTP was the obvious casualty.
9. Move off the legacy mysql driver to mysqli.
10. Use PDO and parameterized queries instead of building SQL by hand.
11. Move user uploads to object storage (something like S3) instead of serving them off the app server.

My first ask was simple: delete every PHP file from the public directory, disable directory listing, add real upload validation, and call me back so we could fix the rest together.

The callback never came. When I checked later, the attacker's web shell was still there. It was still there months after that. The ignorance was the real vulnerability.

Why this mattered

With that level of access, the realistic blast radius on a platform like this was enormous:

1. Thousands of uploaded KYC documents such as scanned PAN cards, Aadhaar, bank passbooks and passports were readable.
2. Wallet balances and prize amounts could be edited at will.
3. Bulk email and SMS could be sent as the company.
4. The website and app source could be rewritten and redeployed. Because real-money fantasy apps are not allowed on the Play Store or App Store, this one was distributed from the company's own site, so a tampered build would have reached every user who updated.
5. Payment integrations could be swapped out.

When a single uploaded file turns into all of that, you can do the maximum damage possible to both the owners and the users. The platform is gone now. I kept the report.