By 
The concrete value of "BEC examples" is that they help decide different controls depending on the fraud objective, and that is where the source material is often fragmented. A single case may be aimed at funds, credentials, or information, may bypass email authenticity if it uses a legitimate compromised account, and calls for something more useful than a single click metric: reporting, out-of-band verification, email monitoring, and evidence preservation.
Placed side by side, BEC examples show that the defense changes more with the attack objective than with the appearance of the email. That comparison makes it possible to see which control to prioritize, what to measure, and where each approach falls short.
| Topic | What it seeks | How it is carried out | Which control to prioritize | What to measure | Control limit | Source |
|---|---|---|---|---|---|---|
| Fraudulent funds transfer | Obtain an unauthorized transfer of funds | Compromise of a legitimate business email account or fraudulent instructions to transfer money, and it may also impersonate a vendor or executive | Confirm payment instruction changes verbally with a known contact, limit authorized users and use dual approval for transfers above a threshold, to new partners, or to new bank accounts | User reports of suspicious emails, analysis time and incident validation, documentation, prioritization, reporting, and evidence preservation | SPF, DKIM, and DMARC reduce forged email, but they do not stop abuse from an already compromised legitimate account | according to FBI IC3, CISA, and NIST SP 800-61 Rev. 2 |
| Credential theft | Obtain information and credentials to compromise accounts | Social engineering in which criminals impersonate a trusted institution, along with infostealers delivered through phishing emails | Enable multifactor authentication and move to phishing-resistant authentication, and train users to identify and report suspicious emails and links | Percentage of participants who changed a work behavior, for example reporting a suspicious email, click rates contextualized by difficulty, and reporting rates | Click rates alone do not provide a complete picture of employee behavior | according to FBI IC3, NIST, NIST SP 800-50 Rev. 1, and IBM X-Force |
| Extraction of personal or corporate information | Request personally identifiable information to compromise other accounts tied to other frauds | Use of a legitimate compromised business account or messages that closely imitate a real organization | Do not respond to requests for financial or personal information by email, contact the person or organization using a legitimate phone number or website, and do not use the information included in the email | Ability to detect, classify, and declare an incident using criteria based on known and suspected characteristics, taking false positives into account, and evidence preservation | The similarity of the fraudulent email to the real company can make the fraud difficult to detect by visual inspection alone | according to FBI IC3, the U.S. Department of Justice, NIST SP 800-61r3 IPD, and NIST SP 800-83 Rev. 1 |
| Domain spoofing and forged email | Impersonate a trusted party to try to get an employee to send money, privileged information, or another asset | Forged or modified email from valid domains and abuse of the organizational email channel | Enable STARTTLS, SPF, and DKIM, and enable DMARC set to reject, plus spam filtering, malware inspection at the gateway, blocking unnecessary file types, antivirus, and sandboxing | Coverage of organizational email authentication and ability to monitor email to detect phishing, data leaks, exfiltration, and other adverse events | Email phishing evolves to evade antispam, antivirus, and sandboxing filters, so awareness and reporting must also be in place | according to CISA and Brazilian government guidance |
Why doesn't "BEC examples" just mean suspicious emails?
The useful reading for a CISO, IT, or compliance team is different: each BEC example works as a test scenario. According to FBI IC3, BEC is a sophisticated scam aimed at companies and people who make legitimate requests for fund transfers, but the same source also describes variants that seek personally identifiable information to compromise other accounts tied to other frauds.
Whalemate reads that as a shift in the unit of analysis. If the example is used only for awareness, the core decision is lost: whether the case seeks to transfer funds, steal credentials, or extract information, because each objective requires different metrics and controls.
What changes when the goal is money, credentials, or information?
According to FBI IC3, a BEC can end in an unauthorized funds transfer through compromise of a legitimate account or through fraudulent instructions sent to the victim. According to FBI IC3 in its phishing alert, criminals also impersonate a trusted institution to obtain information and credentials.
The practical consequence is straightforward. An email asking to change a bank account is not measured the same way as one seeking access credentials or personal data. Whalemate interprets "BEC examples" as something that should organize the defensive program by fraud objective, not by message format.
What do real cases show about how the fraud is carried out?
The U.S. Department of Justice describes a case in which the attacker compromised or impersonated the email of a title company and sent the buyer instructions to wire the down payment to the attacker’s account. According to that same source, the fraudulent email copied the name, address, phone number, email address, logo, and typeface of the real company.
That level of precision matters because it breaks a common assumption. It is not enough to tell users to "look more carefully" at the email. Whalemate understands that these examples test validation and response processes, not just individual visual detection skills.
Are SPF, DKIM, and DMARC enough to stop BEC?
According to CISA Cybersecurity Performance Goals, corporate email should enable STARTTLS, SPF, and DKIM, and DMARC configured in reject mode, because phishing and Business Email Compromise are email-related risks. According to the Brazilian manual based on CIS Controls and the Brazilian Privacy and Security Framework, organizations should also add a gateway with spam filtering, malware inspection, blocking of unnecessary file types, antivirus, and sandboxing.
The tension appears when that is matched against the FBI IC3 operational description. According to FBI IC3, BEC is often carried out when the attacker compromises legitimate business email accounts through social engineering or computer intrusion. Whalemate’s reading is that domain authenticity remains necessary, but it stops being sufficient when the sender is already legitimate.
What happens when the attacker uses a legitimate account?
If the attacker operates from a compromised business account, domain authenticity checks may not trigger enough alerts. According to FBI IC3, that operating model is part of the usual BEC pattern, and the problem is therefore not only forged email but abuse of a real identity.
That changes the defensive decision. According to NIST SP 800-61r3 IPD, organizations need to monitor email, web, file sharing, collaboration services, and other common vectors to detect phishing, data leaks, exfiltration, and other adverse events. Whalemate interprets the BEC example as moving from a social engineering sample to a test of operational visibility over the email channel.
Is click rate alone a useful metric?
According to NIST, click rates alone do not provide a complete picture of employee behavior in phishing awareness programs. But according to NIST SP 800-50 Rev. 1, it is useful to start with current click rates by user group or job function to decide whether more targeted training is needed.
That is not a full contradiction, but it is a tension that is often handled poorly in practice. Whalemate reads the click as a starting point, not a final metric. Useful measurement should also include reporting rates, repeat behavior, and lure difficulty, as the NIST Phish Scale suggests by contextualizing clicks, reports, and users who click repeatedly.
