Bluesage

Case files · real tests · names removed

Real tests. Real doors.

Every story here is true. Only the names are missing.

A selection of our tests across finance, insurance, government, online retail and apps, worldwide. Here is exactly how we got in, how long it took, and what it would have meant.A selection of our tests: how we got in, how fast, and what it would have cost.

Start with case file 01 →Book a pen test
Case file 01 · staff savings platform

Ten minutes. Then the whole company.

One typed line in a login box became control of the server, every app on it, and the money. These are the real steps, in order.

≈10 minfrom the login box to
every system the company runsTIME-LAPSE
  1. 01We typed one line into the staff login box. No password.
  2. 02The system let us straight in, as the administrator.
  3. 03We uploaded a file through the payment receipt form.
  4. 04That one file gave us control of the server.
  5. 05The same server ran the company’s other apps, with their database passwords on it. Every system was open.
  6. 06Hundreds of staff and customer names, phone numbers and bank account numbers.
  7. 07We could change bank details, approve withdrawals to any account (fraud of ₦400m+), take over every system and shut the business down.
Reported.Every step went to the client with the evidence and clear steps to fix it.

Based on a real Bluesage test · client name removed

Case file 02 · NigeriaCustomer help desk

One forgotten file. The whole company.

Five minutes to the main database server. Two days later, any customer account we wanted.

≈5 minto the database server, then about 2 days for the account takeover chain
4 critical3 high3 medium3 low
REPORTED
The side door≈5 minutes
  1. We found a settings file left open to the public.
  2. It held the database password, the mail login and secret keys.
  3. That password opened the company’s main database server.
  4. The same server held the databases of the company’s other systems too: one file, every system.
  5. We created our own administrator account.
The front doorabout 2 days
  1. A booby-trapped link could change a customer’s account details when they simply moved their mouse.
  2. Their login email became ours: full account takeover.
  3. We could send fake “urgent security alert” emails from the company’s own system.
  4. Customer ticket attachments could be opened by anyone.
Read the full case, step by step
The side door≈5 minutes
  1. We found a settings file left open to the public.
  2. It held the database password, the mail login and secret keys.
  3. That password opened the company’s main database server.
  4. The same server held the databases of the company’s other systems too: one file, every system.
  5. We created our own administrator account.
The front doorabout 2 days
  1. A booby-trapped link could change a customer’s account details when they simply moved their mouse.
  2. Their login email became ours: full account takeover.
  3. We could send fake “urgent security alert” emails from the company’s own system.
  4. Customer ticket attachments could be opened by anyone.

WHAT IT COULD HAVE MEANT

Whole company compromisedEvery customer account at riskPhishing from a trusted address
Reported.Every finding went to the client with the evidence and clear steps to fix it.
Case file 03 · NigeriaInsurance claims

Mass financial fraud, no login needed.

Claims on anyone’s policy. Unlimited times. Any amount.

1–2 daysof patient testing
1 critical9 high4 medium
REPORTED
How a claim should workthe normal way
  1. Your phone breaks. You sign in to your own policy.
  2. The insurer checks the phone is really yours, using its unique ID (IMEI).
  3. An agreed repair cost is paid. Once.
What we found1–2 days of testing
  1. The claims system never asked anyone to sign in.
  2. Type in any policy number and you could claim on someone else’s phone.
  3. The same claim could be sent again and again, with no limit.
  4. There was no cap on the repair amount.
  5. The phone ID check ran only inside the web page, so it could simply be skipped.
  6. Parts of customers’ identity details could be read along the way.
What a criminal could domass financial fraud
  1. Collect real policy numbers.
  2. File thousands of repair claims on other people’s policies, for any amount.
  3. Get paid before anyone notices, because every claim looks like normal business.
  4. The result: the claims budget drained and customers’ data exposed, hidden inside everyday claims.
Read the full case, step by step
How a claim should workthe normal way
  1. Your phone breaks. You sign in to your own policy.
  2. The insurer checks the phone is really yours, using its unique ID (IMEI).
  3. An agreed repair cost is paid. Once.
What we found1–2 days of testing
  1. The claims system never asked anyone to sign in.
  2. Type in any policy number and you could claim on someone else’s phone.
  3. The same claim could be sent again and again, with no limit.
  4. There was no cap on the repair amount.
  5. The phone ID check ran only inside the web page, so it could simply be skipped.
  6. Parts of customers’ identity details could be read along the way.
What a criminal could domass financial fraud
  1. Collect real policy numbers.
  2. File thousands of repair claims on other people’s policies, for any amount.
  3. Get paid before anyone notices, because every claim looks like normal business.
  4. The result: the claims budget drained and customers’ data exposed, hidden inside everyday claims.

WHAT IT COULD HAVE MEANT

A claims budget drained by strangersCustomers’ identity details exposedFraud that looks like normal claims
Reported.Every finding went to the client with the evidence and clear steps to fix it.
Case file 04 · NigeriaState government revenue

One sign-up form. The Governor’s email address.

A state revenue portal and its official email platform.

2 daysacross two days of testing
4 critical4 high5 medium2 low
REPORTED
The taxpayer portalday one
  1. Anyone could look up taxpayers’ names, tax IDs and state ID numbers without logging in.
  2. Nothing slowed it down, so the whole tax base could be pulled.
  3. Land records and tax demand notices opened with just a reference number.
The official email platformday two
  1. Anyone could sign up and get bulk-email access on the government’s own system.
  2. It accepted senior officials’ addresses as the sender.
  3. A flaw handed us other users’ one-time login codes: account takeover with no victim click.
  4. Login codes could also be guessed forever, with no lockout.
Read the full case, step by step
The taxpayer portalday one
  1. Anyone could look up taxpayers’ names, tax IDs and state ID numbers without logging in.
  2. Nothing slowed it down, so the whole tax base could be pulled.
  3. Land records and tax demand notices opened with just a reference number.
The official email platformday two
  1. Anyone could sign up and get bulk-email access on the government’s own system.
  2. It accepted senior officials’ addresses as the sender.
  3. A flaw handed us other users’ one-time login codes: account takeover with no victim click.
  4. Login codes could also be guessed forever, with no lockout.

WHAT IT COULD HAVE MEANT

Identity fraud at state scaleFake emails from top officialsAccounts taken over silently
Reported.Every finding went to the client with the evidence and clear steps to fix it.
Case file 05 · United StatesOnline retail

Any website could act as the shopper.

A US online store, tested from the outside.

1 dayof testing
2 high5 medium5 low
REPORTED
What we foundone day
  1. The store trusted logged-in requests from any website.
  2. Checkout didn’t enforce its security token, so purchases could be forged from another site.
  3. The cart accepted unsigned tokens, so its contents could be edited.
  4. Gift card and coupon codes could be guessed with no limit.
  5. Customer usernames were listed publicly.
Read the full case, step by step
What we foundone day
  1. The store trusted logged-in requests from any website.
  2. Checkout didn’t enforce its security token, so purchases could be forged from another site.
  3. The cart accepted unsigned tokens, so its contents could be edited.
  4. Gift card and coupon codes could be guessed with no limit.
  5. Customer usernames were listed publicly.

WHAT IT COULD HAVE MEANT

Accounts read by a malicious pageForged checkoutsGift card fraud

WHAT HELD UP

Payment processingAdmin login protectionSearch and product pages
Reported.Every finding went to the client with the evidence and clear steps to fix it.
Case file 06 · NigeriaOn-demand laundry app

Anyone’s receipt, one number away.

A Nigerian on-demand laundry app: book a pickup, pay from your wallet, track your order.

1 dayof testing
4 high3 medium2 low
REPORTED
How it should workthe normal way
  1. You sign in with a one-time code sent to your own phone.
  2. You only ever see your own orders and payments.
What we foundone day
  1. Payment receipts were numbered in a predictable way. Change a few characters of one and you saw another customer’s payment, email and account ID, plus the server’s internal address.
  2. Login codes could be requested for any phone number, even ones never registered.
  3. Codes could then be guessed with no limit.
  4. The app’s full source code and a push-notification key were open to anyone.
What a criminal could doquietly, at scale
  1. Walk through every customer’s payment history, one receipt at a time.
  2. Guess their way into customer accounts.
  3. Use the push key to send fake alerts that look like they came from the app.
  4. Use the source code as a map for the next attack.
Read the full case, step by step
How it should workthe normal way
  1. You sign in with a one-time code sent to your own phone.
  2. You only ever see your own orders and payments.
What we foundone day
  1. Payment receipts were numbered in a predictable way. Change a few characters of one and you saw another customer’s payment, email and account ID, plus the server’s internal address.
  2. Login codes could be requested for any phone number, even ones never registered.
  3. Codes could then be guessed with no limit.
  4. The app’s full source code and a push-notification key were open to anyone.
What a criminal could doquietly, at scale
  1. Walk through every customer’s payment history, one receipt at a time.
  2. Guess their way into customer accounts.
  3. Use the push key to send fake alerts that look like they came from the app.
  4. Use the source code as a map for the next attack.

WHAT IT COULD HAVE MEANT

Customers’ payments exposedAccounts open to guessingFake alerts from the app itself
Reported.Every finding went to the client with the evidence and clear steps to fix it.
Case file 07 · NigeriaFintech & insurance platform

One default code. Everyone’s identity.

An insurance and finance platform, its admin system and its API.

1–2 daysof patient testing
2 critical3 high6 medium7 low
REPORTED
The front doorfirst
  1. The sign-in system accepted a built-in default one-time code.
  2. That meant getting into accounts without the owner’s phone.
The recordsthen
  1. Change one customer number in a request, and the system handed over someone else’s data.
  2. That included full identity (KYC) records: ID documents and personal details.
  3. The same broken checks let us carry out actions on other people’s accounts.
  4. Some parts of the system answered with data without any sign-in at all.
  5. A file upload accepted dangerous files.
Read the full case, step by step
The front doorfirst
  1. The sign-in system accepted a built-in default one-time code.
  2. That meant getting into accounts without the owner’s phone.
The recordsthen
  1. Change one customer number in a request, and the system handed over someone else’s data.
  2. That included full identity (KYC) records: ID documents and personal details.
  3. The same broken checks let us carry out actions on other people’s accounts.
  4. Some parts of the system answered with data without any sign-in at all.
  5. A file upload accepted dangerous files.

WHAT IT COULD HAVE MEANT

Identity theft at scaleAccounts controlled by strangersRegulatory exposure under data protection law
Reported.Every finding went to the client with the evidence and clear steps to fix it.
How small leaks become big thefts

One small mistake. Then the next. Then the money.

Attackers rarely need one big hole. They chain small ones. These are chains we see again and again, step by step.

What we keep finding

The same six doors, left open again and again.

Across finance, insurance, government and online businesses, the same mistakes keep coming back. If you recognise one, tell us.

Secrets left on public servers

Config files and code folders with database passwords and keys, readable by anyone who knows where to look.

THE FIXBlock dotfiles at the web server and keep secrets in a vault.

Login codes that never lock

One-time codes limited when they’re sent, but not when they’re checked, so they can be guessed.

THE FIXLock the account after a few wrong tries.

APIs that trust any website

Servers that let any website make logged-in requests on a customer’s behalf.

THE FIXAllow only your own websites, by name.

Test systems left online

Development and staging servers on the internet, often with real data and weaker protection.

THE FIXKeep them private and use fake data.

Admin tools with no login

Internal tools and APIs that answer anyone who asks, with no sign-in at all.

THE FIXRequire a login everywhere, by default.

One number away from someone else’s data

Change an ID or a reference number and you see another customer’s records.

THE FIXCheck who owns every record, every time.

From our real reports

What the report says. What it means for you.

Every finding comes in two languages: the technical one your developers need, and the plain one you need to make a decision.

CriticalOWASP A03
SQL injection · authentication bypass

Anyone could log in as the boss. No password needed.

CriticalOWASP A04
Unrestricted file upload · remote code execution

A fake receipt handed over the entire server.

CriticalOWASP A01
Mass personal data exposure via forged cookie

Hundreds of staff bank details, one request away.

CriticalOWASP A05
Exposed .env configuration file

The master keys were left on the doorstep.

CriticalOWASP A01
CSRF · full account takeover chain

Move your mouse over a link, and your account becomes theirs.

CriticalOWASP A07
One-time code returned by an insecure API

Your login code, handed to a stranger. No victim click needed.

HighOWASP A05
CORS reflects any origin with credentials

Any website you visit could act as you on your account.

CriticalOWASP A01
Cross-user claim submission · no login

Strangers could file insurance claims on your policy.

Free consultation

Find out what an attacker would find. Before they do.

Tell us what you run, or what you need built. Rapid response, guaranteed.

Get a free consultation →See our case files
Written permission firstNothing is touched until you sign off.
Careful with live systemsRisky steps are agreed with you first.
Strict confidentialityFindings go only to the people you choose.
Plain-English reportClear for you, detailed for your team.