Phishing remains one of the most common ways attackers get in: a message that appears to come from a manager, the IT department or a supplier, designed to harvest usernames and passwords or to get the recipient to click a link or open an attachment that runs malware[1]. Business email compromise (BEC) goes straight for the money: criminals impersonate or take over a trusted party's mailbox and ask finance staff to send payments to a "new" account. The FBI's Internet Crime Complaint Center (IC3) received 24,768 BEC complaints in 2025 with reported losses of about US$3.05 billion, second only to investment fraud[2].

This article is for IT staff who run email systems, finance and procurement managers who release payments, and executives deciding where to invest. It covers the common techniques and warning signs, the technical and process controls that reduce the risk, and where to get help and report incidents in Taiwan.

Common techniques

Credential phishing and malicious attachments

The most common pattern impersonates a colleague, manager, IT staff member or well-known service, and leads the recipient to a fake sign-in page or to an attachment with macros or malicious links[1]. Email is not the only channel: SMS and collaboration apps such as Teams, Slack and WhatsApp are used as well, and small phone screens make it harder to see the full URL[1].

QR code phishing

The phishing link is embedded in a QR code inside the email or an attachment, with instructions to "scan to verify" or "scan to view a shared file". Hiding the link in an image and moving the user to a phone sidesteps URL filtering and endpoint protection on the company laptop. The rule of thumb is the same as for any link: if a message asks you to scan a code and then sign in with a work account, confirm with the sender through a channel you already know.

Adversary-in-the-middle (AiTM) phishing: when MFA is not enough

More advanced phishing kits run a proxy between the victim and the real sign-in site and relay traffic in both directions. The user sees the genuine sign-in flow and really does complete multi-factor authentication, but the attacker captures both the password and the session cookie issued after sign-in, and can then use the session directly without passing MFA again[3]. Microsoft observed one such campaign attempting to target more than 10,000 organizations from September 2021; in some cases the attacker started payment fraud as little as five minutes after stealing the session, searched finance and invoice threads, replied inside them, and created inbox rules that moved the target's replies to the archive folder and marked them as read so the mailbox owner would not notice[3]. This is why "we already have MFA" does not mean phishing is solved; see the MFA implementation guide for which methods resist it.

BEC and fake vendor invoices

IC3 defines BEC as a scam targeting businesses or individuals who work with suppliers and regularly make wire transfers, in which fraudsters compromise email accounts and other communication channels such as phone numbers and virtual meeting applications, through social engineering or computer intrusion, to conduct unauthorized transfers of funds[2]. Typical scenarios include a "CEO" demanding an urgent transfer, a "supplier" announcing a change of bank account, or an attacker joining a genuine invoice thread. IC3 also reports that in 2025 businesses lost more than US$30 million to BEC involving AI, such as AI-written emails that mimic an executive's tone or voice cloning used to request payments[2].

Impersonation by SMS and messaging apps

In Taiwan, SMS and messaging-app lures that impersonate government agencies or well-known companies are common. In August 2026 the Administration for Cyber Security (ACS) of the Ministry of Digital Affairs warned about texts sent under a look-alike agency name, claiming recipients had to urgently download an "endpoint protection component" because of ransomware attacks and including a short link; the ACS stated that it does not send such messages and never calls people to request transfers[4]. Government SMS messages are being moved to the "111" short code[4], and since June 2025 the ministry has added the last three digits of the recipient's mobile number and the agency name at the start of 111 messages so recipients can check authenticity[5].

Warning signs

Any of the following is a reason to stop and confirm through another channel:

  • Urgency or secrecy, such as "it must go out before close of business" or "don't tell anyone else yet".
  • A request to change the receiving account or to pay a new bank or a personal account.
  • The display name looks right but the full address or domain is subtly different, such as the digit 1 in place of the letter l; on a phone, always expand the full address[6].
  • The link does not match the organization it claims to be from, or a short link or QR code hides the real destination[6].
  • A request to send credentials or personal data by email, or to "sign in again to view" something[6].
  • The other party avoids or refuses confirmation by phone or video.

Technical controls: SPF, DKIM and DMARC

Together these let receiving mail servers check whether a message was really authorized by the domain owner:

  • SPF publishes in DNS which servers may send mail for your domain.
  • DKIM has the sending server sign each message so receivers can verify it with a public key published in DNS.
  • DMARC requires SPF or DKIM to pass with a domain that aligns with the visible From domain, and lets the domain owner state how failures should be handled (none to monitor, quarantine, or reject) and where aggregate reports should be sent[7].

The current DMARC standard is RFC 9989, published in May 2026, which obsoletes RFC 7489[7]. Its recommended rollout is to make sure every system that sends mail as your company, including newsletter, CRM and cloud helpdesk services, has SPF and DKIM in place, then publish p=none with a reporting mailbox, fix legitimate mail streams that fail, and only then consider an enforcement policy[7]. RFC 9989 also advises that domains planning to use reject should first run p=none for at least a month and then quarantine for an equally long period and compare results, and that they must not rely on SPF alone but must apply valid DKIM signatures[7]. Joint guidance from CISA and partner agencies recommends that organizations ultimately set DMARC to reject for the mail they send and enable DMARC checks on the mail they receive[1].

DMARC stops others from spoofing your exact domain, but it does not stop look-alike domains, and it does nothing when an attacker sends from a supplier's genuinely compromised mailbox. Those cases depend on the payment process in the next section. On the account side, enable MFA on mailboxes, monitor internal mail and messaging traffic for suspicious activity[1], and regularly review unusual inbox rules, auto-forwarding and sign-ins from unexpected locations[3].

Verifying payment changes

The most effective control against BEC is not technical: confirm any change to payment details through a second channel[6]. Put this in the finance procedure:

  1. Never accept a new or changed bank account on the strength of an email, text or chat message alone.
  2. Call back using the number in the contract, the vendor master file or past records, never a number or link provided in the request.
  3. Have someone other than the requester approve vendor master changes; add manager approval for large or first-time payments.
  4. Make the first payment after an account change a small test or delay it, and notify the original contact.
  5. Reconcile regularly and look for anomalies such as expected receipts that never arrive; the FBI also recommends regularly reviewing accounts for irregularities[6].
  6. Make sure finance, procurement and executive assistants know that even an urgent request from "the boss" goes through the procedure, and that following it will never be held against them.

If something looks wrong, or money has already left

  • Money already sent: contact your bank immediately to try to stop the funds, call Taiwan's 165 anti-fraud hotline and file a police report[8]. Speed matters.
  • Credentials already entered: reset the password, revoke all active sessions, check inbox rules and forwarding, and review mail sent from the account since the incident.
  • Security incident in a business: companies can request assistance through TWCERT/CC's general incident reporting service, online or by email to int_report@cert.org.tw[9]; phishing sites can be reported to TWNIC's Phishing Check platform[10].
  • Compliance and disclosure: if your company is covered by Taiwan's Cyber Security Management Act or is publicly listed, you may also have reporting or disclosure obligations; see the Cyber Security Management Act and material information disclosure, and the first 24 hours for the order of early response steps.

Action checklist

  • This week, check SPF, DKIM and DMARC records for every company domain; where DMARC is missing, publish p=none with a reporting mailbox.
  • Inventory every third-party service that sends mail as your company, complete SPF and DKIM for each, then plan a stepwise move to a stricter DMARC policy.
  • Enable MFA on all mailboxes and SSO, and move administrators and finance staff to phishing-resistant MFA first.
  • Tag external email, show full sender addresses, and monitor auto-forwarding and unusual inbox rules.
  • Write "payment detail changes require a call-back to a known number plus a second approver" into the finance procedure, and tell key suppliers and customers that you work this way.
  • Prepare a one-page response card: your bank's contact, 165, how to report to TWCERT/CC, and internal security and legal contacts.
  • Refresh awareness training every quarter with real cases from advisories and incidents, or subscribe to phishing-related alerts on this site.