BIPI
BIPI

Financial Services IR: Core Banking Intrusion and SWIFT Anomalies

Cybersecurity

A core banking lateral movement incident or SWIFT messaging anomaly demands a response measured in hours, not days. This playbook covers detection, containment, and the 72-hour regulatory notification clock.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 9, 2024 · 11 min read

#incident-response#financial-services#swift#core-banking#regulatory-compliance#dfir

The 2016 Bangladesh Bank SWIFT heist resulted in 81 million USD in fraudulent transfers before detection. The attackers spent weeks inside the network before sending the fraudulent SWIFT messages, deleting evidence from the SWIFT terminals, and timing transfers to exploit weekend processing delays. In 2024, multiple smaller financial institutions reported SWIFT Customer Security Programme (CSP) audit failures that indicated undetected lateral movement in their environments.

The Financial Services Threat Model

Financial services attackers are motivated by fraud, not just data theft. This changes the IR calculus significantly. A ransomware attacker wants you to know you are compromised. A financial fraud attacker wants to remain undetected long enough to execute transfers. Detection often comes from anomalous transaction behavior, not from security tooling.

  • Initial access most commonly occurs via phishing, VPN credential theft, or third-party vendor compromise.
  • Lateral movement targets domain controllers first, then pivots to core banking systems (Temenos T24, Oracle FLEXCUBE, Finastra Fusion) and SWIFT messaging infrastructure.
  • Attackers establish persistence via legitimate remote access tools (AnyDesk, TeamViewer) installed on compromised servers to survive credential resets.
  • SWIFT fraud requires access to the SWIFT messaging interface, valid operator credentials, and knowledge of SWIFT message formats. This level of sophistication indicates a well-researched, targeted attack.

SWIFT Anomaly Detection: What the Bangladesh Bank Attackers Did

The Bangladesh Bank attackers deleted SWIFT message printer logs, disabled SWIFT audit trails, and used custom malware (evtdiag.exe, msoutc.exe) to manipulate the SWIFT Alliance Access database directly. Modern SWIFT Customer Security Controls Framework (CSCF) v2024 requires anomaly detection on SWIFT messaging systems specifically to counter these techniques.

  1. Enable SWIFT transaction monitoring using the SWIFT Payment Controls service. This provides real-time alerts on transactions that deviate from historical patterns for the institution.
  2. Alert on any SWIFT message transmission outside of normal business hours or to beneficiaries not in the existing counterparty database.
  3. Monitor for SWIFT Alliance Access database queries that are not initiated through the standard SWIFT GUI. Direct database access is a red flag.
  4. Verify that SWIFT audit logs (event logs, message logs) cannot be deleted by the SWIFT operator service account. Log immutability for SWIFT is a mandatory control.
  5. Check for new printer jobs or deleted print spooler records in the SWIFT messaging room. The Bangladesh attackers specifically targeted the confirmation printer to prevent operators from seeing outgoing messages.

Core Banking Lateral Movement: Detection and Containment

Core banking systems are typically among the most sensitive and least monitored systems in a financial institution. Legacy core banking platforms often run on AIX, HP-UX, or mainframe environments with limited integration into modern SIEM platforms. Lateral movement is often detected through database audit logs or application-level access anomalies rather than through network-layer security tools.

  • Pull database audit logs for the core banking system for the 30 days prior to the detected anomaly. Look for queries run by service accounts outside of normal application workflows.
  • Identify any accounts that have been granted elevated privileges within the core banking application in the last 90 days. Attackers frequently elevate privileges within the application tier rather than at the OS level.
  • Check for new API integrations or webhook configurations added to the core banking system. These can be used as persistent data exfiltration channels.
  • Review transaction reversal and adjustment records. Financial fraud often involves creating or reversing transactions to move funds without triggering fraud controls.

72-Hour Regulatory Notification Requirements

Financial services institutions in most major jurisdictions face mandatory incident notification requirements. Under the EU DORA (Digital Operational Resilience Act) effective January 2025, ICT-related incidents classified as major must be reported to the competent authority within 4 hours of classification and 72 hours of initial detection. Under US federal banking regulations, banks must notify their primary federal regulator of a computer security incident no later than 36 hours after determining an incident has occurred.

undefined
undefined
undefined
undefined
undefined
undefined
undefined
undefined
Under US federal banking rules, the 36-hour clock starts when you determine an incident has occurred, not when you confirm scope. Waiting for complete forensic analysis before notifying your regulator is a compliance violation.

Evidence Preservation in Financial IR

  • Preserve all SWIFT message logs, Alliance Access database backups, and operator audit trails before any system changes.
  • Capture core banking application logs, database audit trails, and transaction records for the full suspected compromise window.
  • Preserve firewall logs and proxy logs for all SWIFT infrastructure network segments.
  • Document all transaction records that were created, modified, or deleted during the incident window. These are simultaneously forensic evidence and the basis for any recovery of fraudulent transfers.
  • Engage external counsel with financial regulatory experience before making any statements to the regulator. The incident notification and subsequent communications may be used in enforcement proceedings.

Recovery and SWIFT CSP Revalidation

Following a confirmed SWIFT-related incident, your SWIFT relationship manager will initiate a CSP compliance review. You will need to demonstrate that all mandatory controls are in place before full SWIFT connectivity is restored. Engage your SWIFT CSP assessor immediately after containment to begin the revalidation process in parallel with the forensic investigation.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.