The Bangladesh Bank heist disclosed on the 8th of March is the most operationally instructive financial-services incident I have read about this year, and the public detail is firming up daily. The headline is well-known: on the 4th and 5th of February, a series of fraudulent SWIFT messages were sent from the Bangladesh Bank's network to the Federal Reserve Bank of New York, instructing transfers from the bank's Fed account to accounts in the Philippines and Sri Lanka totalling close to a billion dollars. Five of the thirty-five transfer messages, totalling eighty-one million dollars, were processed before the Federal Reserve flagged the remaining transfers as suspicious. The SWIFT messages used legitimate credentials and were properly authenticated within the SWIFT system. The Federal Reserve, on its own subsequent statement, treated them as legitimate.
The reason the remaining transfers were flagged is the part of the story that should make every banking CISO uncomfortable. The transfer instructions used the word "Jupiter" in the address line — Jupiter being the name of one of the recipient accounts at Rizal Commercial Banking Corporation in the Philippines. Jupiter is also the name of a sanctioned Iranian shipping company. The Federal Reserve's automated sanctions screening system flagged the messages on that name match. Without that coincidence — and it is a coincidence, the recipient was unrelated to the sanctioned entity — the full $951 million would, on the evidence so far, have been transferred (Reuters reconstruction, "How a hacker's typo helped stop a billion dollar bank heist"). The defensive control that worked was a sanctions-screening false-positive, not any control that the Bangladesh Bank had in place against unauthorised SWIFT messaging.
The technical reconstruction so far. The attackers had been resident in the Bangladesh Bank's network for some weeks, possibly months. They had administrative access to the SWIFT-connected workstation, which is the dedicated terminal used to compose, authenticate, and submit SWIFT messages. They had compromised credentials of bank operators who had legitimate authority to authorise transfers. They timed their fraudulent messages to coincide with a Bangladesh weekend and a US Federal Reserve weekend, which produced a delay in any reconciliation between the bank and the Fed. They installed malware on the SWIFT terminal that — and this is the detail that BAE Systems published in their preliminary report on the 26th of April (BAE Systems blog post on the SWIFT attack tooling) — modified the bank's local copy of the Alliance Access SWIFT software to suppress confirmation messages. SWIFT's own system was not compromised; the local SWIFT-client software was modified to mislead the bank's own logging and reconciliation about what had been sent. The bank's printed confirmation reports for the 4th and 5th of February showed the transfers as never having been requested.
The pattern matches Carbanak. Patient initial access, careful reconnaissance of the operational workflow, instrumentation of the operator workstation, and execution at a moment chosen for low-detection probability. The technical implant differs in detail — the Alliance Access modification is specific to the SWIFT product — but the operational philosophy is the same. The threat group attribution chatter has been pointing variously at the Lazarus Group (the cluster associated with the 2014 Sony Pictures breach), at North Korean state activity, and at miscellaneous criminal actors. Symantec and Kaspersky have both produced indicator-of-compromise overlaps with earlier Lazarus tooling (Symantec blog post on shared code) but the public attribution is preliminary and I expect the picture to firm up over months, not weeks.
For the financial-services pen testing work and the vCISO clients with banking exposure, the operational lessons are concrete. The SWIFT-connected workstation is, in many institutions, treated as a special device with restricted access but not necessarily with the kind of behavioural monitoring that would catch an in-tenant intruder. The session that authenticated the fraudulent messages used legitimate credentials; the controls that should have caught the attack are the ones that watch what authorised users actually do. Time-of-day baselines for SWIFT messaging volume and destination diversity. Out-of-band confirmation for any transfer above a configurable threshold, particularly those involving correspondent-bank accounts the institution has not previously transacted with. Network segmentation that places the SWIFT terminal in its own zone with strict ingress and egress controls, and inline monitoring of any administrative access to that zone. The Bangladesh Bank reportedly did not have many of these controls; their SWIFT terminal was reachable from the broader bank network, the network was reachable from the internet, and the inter-bank reconciliation cadence was lax enough that the fraudulent transfers ran for two days before discovery.
The wider concern is the SWIFT-system-as-trust-anchor question. SWIFT itself has issued statements emphasising that their network was not compromised, which is true and important — but it is not the whole story. The trust model of the SWIFT network is that messages from a member institution have been properly authenticated by that institution's local controls. If a member institution's local controls are insufficient, fraudulent messages enter the network with full validity. The systemic risk is to every member institution from the weakest member institution. SWIFT has announced (SWIFT customer security programme press release, May 2016) the Customer Security Programme, which will set baseline local-control requirements for member institutions and audit attestations against them. That is the right structural response and several years overdue.
The post-incident customer briefing that I am preparing for the next vCISO board cycle will cover three things. The Bangladesh Bank attack as the operational example of why identity-as-perimeter still does not work for financial-services back-office systems, building on the Carbanak material from 2015. The behavioural-control posture I want to see on every customer's payment-message origination workstations, which is more rigorous than what most of them have today. And the SWIFT CSP, which will show up in every banking customer's compliance landscape over the next twelve months and which I want them to be ready for as an opportunity to do real work, not as a tick-box exercise.