The Bangladesh Bank heist that I wrote about in March is, on the evidence accumulated over the past six months, not an isolated event. SWIFT issued a series of customer alerts in May, June, and August this year (SWIFT customer security notice page, swift.com) describing additional fraudulent-transfer attempts at member institutions. Banco del Austro in Ecuador (disclosed via litigation rather than direct attribution, $12 million) and Tien Phong Bank in Vietnam (foiled, attempted via the same Alliance Access modification pattern) are the publicly named additions. The SWIFT alerts reference further institutions confidentially. The cadence of the disclosures and the technical similarity in the published indicators-of-compromise across cases indicate that the same actor or actors are running an ongoing campaign against multiple member institutions.
The technical pattern is consistent across the disclosed cases. Initial access through credential or workstation compromise at the member institution — the specific vector varies (spear-phish in some cases, third-party support compromise in others, possibly insider involvement in at least one). Resident reconnaissance and operator surveillance over weeks or months. Modification of the Alliance Access local installation to suppress confirmation messages and printed reconciliation. Fraudulent transfer messages timed to exploit weekend or after-hours reconciliation gaps between the originating institution and the correspondent bank. Mule-account structures for receipt and downstream cash-out, predominantly in jurisdictions with weak anti-money-laundering enforcement.
The SWIFT Customer Security Programme that I mentioned in March has now been formally launched (SWIFT CSP customer programme overview). The programme defines a baseline set of mandatory security controls — sixteen controls in the initial framework, addressing areas like privileged-account management, network segmentation, multi-factor authentication on payment-system access, integrity protection for the local SWIFT software installation, and incident-response readiness. SWIFT member institutions will be required to attest to compliance against the controls annually, and SWIFT has indicated that non-attesting members may face commercial consequences from their counterparties even if SWIFT itself does not directly enforce the controls. The programme is a substantial structural change in the SWIFT trust model — moving from "members are trusted, network is secured" to "members are audited, network and members are secured" — and is the right direction.
The implementation question for member institutions is harder. The CSP controls are reasonable on paper. The operational work to bring a typical mid-sized member into attestable compliance — privileged-account management hardening, network segmentation review and rebuild, payment-system MFA enrolment, integrity-monitoring deployment, behavioural-analytics on operator workstations — is six to twelve months of dedicated programme work for an institution that is starting from a typical maturity level. Several of the institutions we have spoken to in the financial-services pen-testing engagement queue this summer have been on attestation timelines that are, to put it diplomatically, optimistic. The programme is going to drive a substantial wave of consulting and engineering work over the next eighteen months, and the institutions that engage with it as a real programme rather than as a tick-box compliance exercise will end up materially more secure. The institutions that engage with it as a tick-box exercise will end up with attestable but operationally weak programmes, and will be the next targets.
For the SOC operation, the technical indicators across the disclosed cases have been incorporated into our detection content. The signatures are conservative — the specific Alliance Access modification patterns, the C2 infrastructure overlaps, the operational-tooling hashes — and the false-positive rate against customer banking estate has been zero in production. The harder detection question is the one that does not respond well to signature work: behavioural anomalies in payment-message origination by authenticated users. The work we are doing on alert-triage machine learning may be relevant here in ways we have not yet explored — the input features for "did this user do this thing in this manner" are richer for payment-system telemetry than for general SOC alerts, and the analyst-decision data is correspondingly richer. I am not yet ready to say more. There is interesting work there.
The wider strategic point — which I am writing into the next round of vCISO board briefings — is that the SWIFT campaign demonstrates a particular kind of professionalised criminal capability. The actors are sophisticated, the operations are sustained, the targets are selected for specific operational characteristics, and the take is in the tens of millions per successful operation. This is not opportunistic crime. It is a small number of organisations running a high-touch, low-volume, high-yield enterprise. The defensive posture has to assume that any given member institution is a potential target, that the targeting decision is made on the basis of operational characteristics the institution may not be aware of (legacy SWIFT-client software, weak privileged-account controls, predictable reconciliation cadences), and that the dwell time available to the attacker is months. None of that is unfamiliar in the abstract. The Bangladesh Bank case made it concrete.
The blog has been busy this summer. The DNC and Shadow Brokers material has been in the foreground; the SWIFT pattern has been a quieter background piece, less newsworthy because the press cycle has moved on after the original Bangladesh story. The financial-services security community has not moved on. The work continues, mostly in confidence, mostly invisible to the public eye. I want to keep writing about it because the lessons are operationally important and the public attention is, at this distance, inadequate to the scale of what is happening.