AS/400 (IBM i) core banking penetration test: a case study

A large private bank asked us a simple question before migrating its core banking platform. If someone got inside our network, how far could they go? The answer was uncomfortable: far enough to change account balances. This is how we found that route, and how the bank closed it without delaying its plans.

The bank and what it needed

The bank’s core ledger runs on AS/400 (an IBM midrange computer, now called IBM i, that many core banking platforms still run on). It serves more than 600 branches. The core also connects to the payment switch and to BI-RTGS, Bank Indonesia’s system for settling large interbank payments.

The bank wanted assurance for two reasons: the planned migration, and its next audit by OJK (Indonesia’s Financial Services Authority). The test could not cause any downtime at the branches.

Why an older system still carries risk

Many teams assume an AS/400 is safe because few attackers understand it. That assumption does not hold up well. Over the years, these systems collect powerful accounts, shared passwords and old connection methods that nobody reviews. At this bank, nobody had tested the route from the office network into the core for five years.

How we went about it

We ran an assumed-breach test. That means we started as if an attacker already had a foothold on the internal network, for example through an employee’s compromised laptop. From there we tried to reach the core, as a real intruder would.

We looked at every way people and programs connect to the AS/400, who holds which powers on the system, and whether the database could be changed directly without going through the banking application. We also checked whether a foothold on the core could be used to reach the payment gateway. The work followed two public testing standards, PTES and NIST SP 800-115, and was carried out by CREST-certified testers. Anything that could change data was proven only in the test environment and then reversed.

What we found

The most serious problem was a service account (an account used by software, not by a person). It had full authority over every object on the system, and its password sat unencrypted in a configuration file. With it, we could connect straight to the database and change an account balance. We proved this in the test environment by adding Rp1 to a test account, then reversing it.

Two other problems were rated high. The system’s built-in master security account was still active. Six ordinary user profiles also shared job-control powers through a group, which let us act as the system operator. Separately, terminal sessions ran without encryption, so anyone on the local network could list user names and take over sessions.

In total we reported 21 findings: 1 critical, 4 high, 7 medium and 9 low.

What the bank changed

The bank removed the excessive authority and moved the service account’s password into a secure vault. It turned on encryption for terminal sessions and added exit programs (IBM i controls that screen incoming connections). It also restricted who can submit jobs to the system. The critical issue was fixed within 48 hours, a retest confirmed the fixes held, and the migration stayed on schedule.

The auditor accepted the test evidence. The bank has since adopted a standard IBM i hardening baseline across its estate. It now runs a quarterly internal retest, with a configuration checklist, ahead of each OJK cycle.

Technical detail for the IBM i team

  • Environment: IBM i V7R4, DB2/400, 5250 applications, MQ bridge to the payment switch and BI-RTGS
  • Critical: service account with *ALLOBJ authority and plaintext ODBC credentials in an .ini file allowed a direct UPDATE to ACCTBAL (PoC: +Rp1 in UAT, rolled back)
  • High: QSECOFR not disabled; 6 profiles holding *JOBCTL through a group profile enabled pass-the-job to QSYSOPR
  • High: TN5250 without TLS and without an exit program, allowing user enumeration and session hijack on the LAN
  • Also covered: FTP, ODBC, MQ, job queues and spool files, adopted authority, *SECADM holders, password policy, SQL injection through the 5250 wrapper, and lateral movement from the job submitter to the SWIFT/MQ gateway
  • Findings mapped to ISO/IEC 27001 A.8, SOC 2 CC6.1 and PCI DSS 4.0 Requirements 7 and 8
  • Report within 10 days of testing, retest included

If your core still runs on AS/400, it is worth asking when anyone last tried to reach it from the inside. We are happy to talk through what a similar test would involve for your bank.