One unsanitised parameter on an internal portal, and an attacker is reading customer accounts. Here is the real path a banking SQLi takes.
A core banking injection rarely starts on the public site. It starts one or two hops inside: an admin portal, a support panel, a legacy web service that talks to the database with a concatenated query. The perimeter looks clean, so the query was never reviewed.
Once the first union or error-based response works, the attacker maps the schema and escalates to reading account balances, transaction logs and card tables — often with the database account that has the broadest rights, because it was convenient at the time.
An automated scanner sees a parameter, sends a quote, checks for a signature, and moves on. A banking SQLi often hides behind multi-step flows, custom encoding, or a WAF that the app itself bypasses on internal calls. You need a human who follows the money and the login walls to the actual query.
Most findings reproduce on a staging or UAT environment that mirrors the portal and database. Live verification, when required, runs in an agreed window.
Yes — under an NDA and a signed scope. We test only systems you own or are authorised to assess.