Engagement record
- Sector
- Retail and corporate banking
- Scope
- Internet banking web applications, banking APIs, Android application, ATM and CDM estate, banking servers and network, desktop applications
- Shape
- Single consolidated engagement, one report
- Driver
- Regulator expectation for independent testing, plus internal audit
- Confidentiality
- Client not named; findings described by class
Context
Banks are tested more than almost any other sector, and breached anyway. The usual reason is not that testing is absent. It is that testing is split across vendors by asset type. One firm takes the web application, another the network, a third the mobile app. Each report is competent and each stops neatly at its own boundary.
Attackers do not respect those boundaries. They enter through whichever surface is weakest and move toward whichever is most valuable, and the path between the two is the space no single vendor was scoped to look at.
Approach
One scope, one team
All six asset classes were tested in a single engagement by the same team, so knowledge from one surface carried directly into the next. An identifier format learned in the mobile application was immediately testable against the internet banking API.
Assumed breach on the internal side
Internal testing started from a standard domain user rather than spending days on initial access, because phishing eventually succeeds against every organisation. The useful question was how far one workstation reaches.
Terminals in a controlled environment
ATM and CDM testing was performed against units in a lab and a controlled branch environment, never against a live customer-facing terminal. Coverage included kiosk escape, exposed interfaces, terminal-to-host communication and hardening.
Chains before singles
Findings were escalated to their maximum realistic impact and written as end-to-end paths rather than as a severity-sorted list.
Splitting testing by asset type produces findings that stop at each boundary. Attackers never do.Engagement note
What was found
Findings are described by class and impact. Reproduction detail stays in the client’s report, a case study that hands a reader a working attack against a former client is a breach, not marketing.
| Class | What it meant |
|---|---|
| Authorisation | Object references reachable across customer boundaries on paths that the interface never exposes: exports, statements and support tooling. |
| Channel inconsistency | Controls enforced in one channel and assumed in another, where the same backend served both. |
| Internal network | Standard-user-to-elevated paths through credential hygiene and directory misconfiguration, of the classes covered on the network service page. |
| Terminal surface | Exposed interfaces and hardening gaps on self-service units. |
| Transaction logic | Limit and confirmation controls bypassable by changing the order of operations rather than by breaking any single control. |
Outcome
The report set out the full attack path across channels rather than six independent findings lists, which is what the risk committee needed to size the exposure. Every finding was retested after remediation in a clean session and closed only when re-exploitation failed.
The structural lesson generalised beyond this bank: consolidating channels into one engagement surfaced findings that per-asset testing had not. The previous testers were not weaker; the path between two assets simply belonged to neither scope.
Questions
How long does a bank penetration test take?
A bank penetration test spanning six asset classes runs in weeks rather than days, as one continuous engagement rather than six bookings. Internet banking, the banking APIs, the Android application, the servers and network, the ATM and CDM estate and the desktop applications were covered by one team in a single run, with a retest after remediation.
Our core banking platform is vendor-hosted. Does the vendor's penetration test cover us, or do we need our own?
A vendor's penetration test covers the vendor's platform, not your configuration of it, the channels built on top, your user roles or your internal network, so it does not replace testing your own estate. Ask the vendor for their report, then scope your own test around everything it excludes.
If our mobile app and internet banking share the same backend, do we need to test both?
Yes, a mobile application and an internet banking site that share one backend still need testing separately, because a shared backend does not mean shared enforcement. Controls enforced in one channel but only assumed in the other were a confirmed finding class on this engagement. Testing one channel tells you how that client behaves, not what the API accepts when another client asks.
Why do banks that pass annual penetration tests still get breached?
Banks that pass annual penetration tests still get breached because the testing is split by asset type, so the route an attacker takes crosses a boundary no report was scoped to cover. Consolidating six banking channels into one engagement surfaced what per-asset testing had not: an identifier format learned in the mobile application was testable against the internet banking API.
Can a penetration test prove one customer can access another customer's accounts or statements?
Yes, that is broken object-level authorisation, commonly called IDOR, and it is proven by replaying one customer's object reference from a second account's session. In this bank's scope, object references were reachable across customer boundaries on paths the interface never exposes: exports, statements and support tooling.
Can a penetration test find OTP or transfer limit bypasses in internet banking?
Yes, transfer limit and OTP confirmation bypasses are a standard business logic target, and the route is usually the order in which operations are called rather than a broken control. In this bank's scope, limit and confirmation controls were bypassable by changing the order of operations, while each control held when called in the expected sequence.
Do we get one penetration test report, or one per asset class?
One report covers every asset class in the engagement, rather than one report per asset. It sets out the attack path across channels instead of six independent findings lists, which is what the bank's risk committee needed to size the exposure.