Banco de Chile — MBR wiper and SWIFT theft

What happened

On 24 May 2018, staff arriving at Banco de Chile branches and offices found that approximately 9,000 workstations and 500 servers would not boot. A variant of the KillDisk wiper malware had been deployed across the bank’s Windows corporate environment overnight, overwriting the master boot record on each machine and rendering it unbootable. Branches switched to manual transaction processing. The IT organisation mobilised to respond to what appeared to be a significant destructive attack against the bank’s corporate infrastructure.

The destructive attack was deliberate misdirection. Simultaneously with — and taking advantage of the operational chaos caused by — the wiper deployment, the attackers issued four fraudulent SWIFT messages through Banco de Chile’s SWIFT infrastructure, routing approximately $10 million to accounts at banks in Hong Kong. The bank’s SWIFT operations were on a network segment separate from the wiped corporate estate, and the SWIFT terminals were not among the systems rendered inoperable. The combination of the crisis response consuming the bank’s operational attention and the deliberate network separation between the wiper targets and the SWIFT infrastructure gave the attackers the window they needed.

Chilean financial authorities and SWIFT worked with Banco de Chile to identify and partially recover the fraudulent transfers. Approximately $6 million was recovered or frozen before it could be fully laundered; the estimated net unrecovered loss was approximately $4 million. Banco de Chile confirmed publicly that customer-facing services — ATMs, branch transactions — were not affected because they ran on infrastructure separate from the wiped corporate estate. US and Chilean investigators attributed both the wiper deployment and the SWIFT fraud to the Lazarus Group, the North Korean state-sponsored hacking organisation responsible for the 2016 Bangladesh Bank SWIFT heist.

How it worked

The Banco de Chile operation combined two distinct technical components: destructive malware for the misdirection layer and SWIFT-system compromise for the theft layer.

The wiper deployed was a variant of KillDisk, a destructive malware tool associated with multiple Lazarus and Russian APT operations since at least 2015. KillDisk, in its master-boot-record-overwriting configuration, replaces the MBR of each targeted machine with code that overwrites itself repeatedly on boot, rendering the machine unbootable and — depending on configuration — beginning to overwrite disk sectors. The resulting disruption is immediate and visible, requiring manual recovery effort for each affected machine. The deployment across 9,000 endpoints at Banco de Chile required either broad domain administrative access (obtained through prior lateral movement) or a mechanism for propagating the wiper across the network — consistent with Lazarus’s standard operational pattern of extended pre-deployment reconnaissance and lateral movement.

The SWIFT fraud component followed the methodology first demonstrated in the 2016 Bangladesh Bank heist. Lazarus operators gained access to the bank’s SWIFT messaging infrastructure — either directly, through a compromised endpoint with access to the SWIFT terminal, or through malware that intercepted and manipulated SWIFT messages — and issued transfer instructions that appeared to originate from Banco de Chile’s legitimate SWIFT credentials. The four messages routed approximately $10 million to a network of accounts in Hong Kong established to receive and launder stolen SWIFT transfers. The launderer accounts received the funds, began breaking them into smaller transfers, and in part converted them before detection and freezing orders reached the correspondent banks.

The diversion relationship between the two components is the operational innovation. A bank experiencing a large-scale wiper attack will direct its incident response resources — IT, security, management — at the visible crisis. SWIFT anomaly detection and the slower out-of-band communication required to intercept international wire transfers competes for attention with an emergency affecting thousands of desktops. The Lazarus operators understood this resource-allocation dynamic and designed the operation accordingly.

Timeline

• Weeks to months before 24 May 2018 — Lazarus operators gain access to Banco de Chile’s corporate network; conduct reconnaissance, escalate privileges, identify SWIFT infrastructure and corporate Windows estate; stage wiper payload.
• Night of 23–24 May 2018 — KillDisk MBR wiper deployed across approximately 9,000 workstations and 500 servers.
• 24 May 2018 (morning) — Bank staff arrive to find corporate systems unbootable; branches activate manual procedures; IT teams respond to wiper crisis.
• 24 May 2018 — Attackers submit four fraudulent SWIFT transfer messages totalling approximately $10 million, routing funds to Hong Kong accounts. Fraud discovered shortly after; SWIFT and correspondent banks notified.
• May–June 2018 — Approximately $6 million recovered or frozen through SWIFT correspondent bank cooperation; net loss approximately $4 million.
• 2018 — SWIFT issues updated customer security programme guidance citing the Banco de Chile incident; Chilean financial regulator opens review of banking cybersecurity requirements.
• 2018–2019 — US and Chilean intelligence attribution to Lazarus Group confirmed; operation placed in the Lazarus SWIFT heist series alongside Bangladesh Bank (2016) and FASTCash operations (2018 onwards).

What defenders should learn

The Banco de Chile operation teaches a lesson about attacker sophistication that has direct implications for how incident response is structured. When an incident appears to be what it is — a large-scale destructive attack requiring all-hands response — the correct question is also whether it is simultaneously something else. A principle that every incident-response team should practice is examining what the visible attack may be designed to distract from: what high-value systems are accessible, what privileged channels could be used during the response window, and whether the specific timing and targeting of the visible attack serves any misdirection purpose.

The SWIFT infrastructure lesson is the most specific and actionable. Banco de Chile had separated its SWIFT terminals from its corporate Windows estate — which is why the wiper did not disable the SWIFT infrastructure. But that network separation, correct as it was, did not prevent the SWIFT fraud because Lazarus had already compromised the SWIFT credentials during the pre-deployment phase. Physical and network separation of SWIFT infrastructure from corporate systems is necessary but not sufficient; it must be combined with robust SWIFT transaction monitoring, anomaly detection on the volume and destination of outbound SWIFT messages, and multi-person authorisation for large-value transfers that cannot be overridden by a single compromised credential.

SWIFT responded to the Bangladesh Bank heist and the subsequent series of Lazarus attacks by introducing its Customer Security Programme (CSP), a set of mandatory security controls for SWIFT member institutions. Compliance with the CSP became obligatory from 2018. The Banco de Chile incident occurred during the first year of mandatory CSP compliance and reflects either partial implementation or implementation gaps in the specific controls most relevant to credential compromise and transaction monitoring. The CSP framework has been incrementally strengthened since 2018, but its effectiveness depends on full and genuine implementation by member institutions.

The Banco de Chile incident should also be read as the first data point in the Lazarus FASTCash pattern that has since been documented across attacks against banks in Africa, South Asia, and Latin America. The specific combination of pre-deployment access, diversion malware, and SWIFT fraud is a repeatable playbook. Banks in the affected regions that have not reviewed their SWIFT credential security, transaction monitoring, and incident-response procedures in light of this playbook are carrying documented, attributed risk.