File-borne breach events · East Asia
Taiwan: documented file-borne breach events
Taiwan's record runs from the 2016 First Commercial Bank ATM heist, traced by investigators to a spear-phishing email, to D-Link's own 2023 confirmation that a phished employee was the route into its systems.
Overview
What the record shows
Taiwan investigates and prosecutes cyber incidents more visibly than most of the region, through the Ministry of Justice Investigation Bureau, and the 2016 First Commercial Bank heist is its best documented file-borne case. Investigators traced initial access to a spear-phishing attack on a call centre serving the bank's London branch, months before the attackers pivoted into the Taiwan network and dispensed cash from 41 ATMs through the bank's own software update server.
Precision matters here: the MJIB's published brief documents the intrusion chain from the compromised London server onward, while the spear-phishing entry and its Office exploit attachments come from investigators' accounts carried in reputable reporting. The entry below says exactly that. Other Taiwanese headliners stay off this record: the 2017 Far Eastern International Bank heist's entry point was never documented, the 2020 CPC Corp ransomware vector was never determined, and the 2018 TSMC infection travelled on equipment rather than through a content channel.
Documented events
File-borne incidents in Taiwan
Most recent first. Every entry cites the public record it is drawn from.
-
D-Link Corporation: Networking manufacturer confirmed a phished employee as the route into its systems
After data purporting to come from D-Link was offered for sale in October 2023, the company investigated with an external incident response firm and confirmed unauthorised access traced to a phished employee. D-Link says the exposed records came from an outdated product registration system and covered approximately 700 low sensitivity records.
The documented vector. Phishing email against an employee; D-Link's advisory does not specify the message mechanics further. D-Link's own support announcement states the incident was caused by an employee falling victim to a phishing attack. The advisory does not specify whether the message carried an attachment or a link, and this entry carries that limit rather than filling it in.
How this class of vector is removed
The record names phishing as the route but not what the message carried. Inbound mail is processed before it reaches anyone rather than trusted on the strength of its sender, and a carried document is rebuilt to its format's known good specification, which is what this class of vector usually turns on and does not depend on the reader spotting anything. The record does not establish what arrived, so this is held at low confidence. D-Link's advisory does not say what the message carried, so this entry claims nothing about it.
Email CDR RelayContent Disarm and ReconstructionGlasswall Halo / Glasswall Meteor / Glasswall Genesis
- manufacturing
-
First Commercial Bank: ATM heist cashed out through the bank's own update server after an intrusion through the London branch's call recording server
In July 2016 the Cobalt group withdrew about NT$83 million from 41 First Commercial Bank ATMs in Taipei, using malware distributed through the bank's own ATM software update server after a network intrusion first observed in firewall logs on 31 May 2016, when the London branch's call recording server connected to an unknown Swiss IP address. The MJIB investigated, three money mules were convicted in Taiwanese courts and most of the cash was recovered.
The documented vector. Network intrusion via the London branch's call recording server; no file vector established in the published record. The Ministry of Justice Investigation Bureau's published brief gives the entry point as the call recording server at the bank's London branch: on 31 May 2016 the firewall log showed that server making abnormal outbound connections to an unknown Swiss IP address, and the intruders went on from it into the bank's intranet. The brief records no email, attachment or document in that chain. AmCham Taiwan's reporting adds that the initial access came through a spear-phishing attack on a call centre worker serving the London branch and that the emails "may have" delivered attachments exploiting a Microsoft Office vulnerability, attributing that to news reports; the official record does not carry it.
Note on this entry
The official record documents a server intrusion from an external IP address and the malware push through the bank's own ATM update server; the spear-phishing attachment account rests on news reports and is hedged as "may have" in the one secondary source that carries it. No file vector is established in the published record, so no prevention analysis is published for this event.
- banking
Source: Ministry of Justice Investigation Bureau · Source: Taiwan Business TOPICS (AmCham Taiwan) · Source: Group-IB
Scope
How to read this page
Every event on this page meets three tests before it is published. It is documented by reliable public sources: a regulator, an official inquiry, the affected organisation's own disclosure, or reputable press with named confirmation, and each entry links to those sources. The initial access or payload delivery travelled as a file, as the public record states it. And where an entry carries a prevention analysis, that analysis is bounded by what we can evidence; where an entry carries none, that is deliberate.
About the organisations named here. They are named because the public record names them, and for no other reason. Nothing on this page alleges fault, negligence or any breach of duty by any organisation or individual, and nothing here should be read as saying that anyone acted improperly or that their security arrangements were inadequate. Being attacked is not evidence of either, and the organisations on this page include some of the most heavily defended in the region. We summarise what published sources report and link to them so you can read them yourself. We have not independently investigated any incident and we hold no non-public information about any of them. Names are used to identify the organisations concerned; no affiliation with them, and no endorsement by them, is implied, and all trade marks remain their owners'.
About the prevention analysis. Where an entry describes how a class of vector is addressed, that is a general statement about how a control treats that class of content. It is not a claim that our products were in use, that they would have been deployed in that architecture, or that they would have prevented that incident. It is not an assessment of any organisation's actual controls, which we do not know. What a control achieves in practice depends on configuration, deployment and file type. Where an entry carries no prevention analysis, we are making no claim about that event either way.
Generally. This page is a working reference, not an incident report, a security assessment or legal advice, and it is provided without warranty. Details reflect the public record on the review date and may have changed since. If you believe anything here is inaccurate, incomplete or out of date, tell us and we will review it promptly and correct it where the record supports that.
Elsewhere in the region