I7.5 Business Email Compromise and Impersonation
Learn how defenders evaluate fictional executive impersonation, vendor fraud, payroll diversion, invoice manipulation, gift-card requests, compromised mailboxes, reply-chain abuse, transaction holds, account recovery, validation, and evidence-based closure.
Lesson Progress
Business Email Compromise and Impersonation
High School Intermediate • I7: Email Security and Phishing Defense • Lesson 5 of 8
Readiness Check
Before You Start
0/5 ready
Professional Hook
A Real Sender Domain Does Not Make a Financial Request Safe
A fictional vendor mailbox can be compromised while its SPF, DKIM, and DMARC results continue to pass. A real conversation can be used to introduce new banking details. A leader’s correct name and title can be copied into a gift-card request. Defenders protect the business by combining sender, account, transaction, approval, process, and independent-verification evidence.
Weak response
“The fictional vendor domain authenticated correctly, so update the bank account before the deadline.”
Strong response
“Pause the change, verify through the known vendor contact and procurement process, review account evidence, and validate the final transaction state.”
Objective 1
Explain fictional business email compromise, executive impersonation, vendor fraud, payroll diversion, gift-card requests, invoice manipulation, and reply-chain abuse.
Objective 2
Distinguish direct spoofing, lookalike-domain impersonation, compromised legitimate accounts, forwarded conversations, shared mailboxes, and authorized third-party senders.
Objective 3
Evaluate fictional financial and business requests using sender identity, authentication, business process, transaction records, approvals, account activity, and independent verification.
Objective 4
Design narrow defensive response steps that protect payments, payroll, data, accounts, and legitimate communication without making unsupported claims.
Objective 5
Create a professional fictional Business Email Compromise Case Report with evidence, findings, owners, containment, validation, monitoring, and residual risk.
Why This Matters
BEC Targets Decisions, Not Just Inboxes
Business email compromise becomes dangerous when a message changes a payment, payroll destination, vendor record, data transfer, account, permission, purchase, or approval. A strong defense places controls around the decision itself. Even when a deceptive message reaches an inbox, independent verification, separation of duties, transaction holds, and owner approval can prevent impact.
BEC Patterns
Eight Business Email Compromise Patterns
Executive gift-card request
Fictional message
A fictional leader asks an assistant or employee to buy gift cards quickly and keep the request confidential.
Pressure
Authority, urgency, secrecy, and an unavailable-by-phone explanation.
Defensive control
Require the normal purchasing process, known-contact verification, budget approval, and transaction records.
Evidence
Sender identity, domain, message content, purchasing policy, leader confirmation, user action, and payment activity.
Vendor bank-account change
Fictional message
A fictional supplier asks that future invoices be paid to a new bank account.
Pressure
Urgent payment deadline, attached confirmation, changed contact details, or a request to avoid the normal portal.
Defensive control
Pause the change and verify through the known vendor contact and approved procurement workflow.
Evidence
Vendor master record, purchase order, prior invoices, known contact, authentication, reply chain, bank-change request, and owner approval.
Payroll direct-deposit update
Fictional message
A fictional employee or executive requests a new salary-deposit account through email.
Pressure
Upcoming payroll deadline, travel, account problem, or inability to use the normal system.
Defensive control
Use the approved payroll portal and identity-verification process rather than email instructions.
Evidence
Employee record, mailbox evidence, payroll workflow, identity verification, session activity, factor changes, and direct-deposit history.
Invoice amount or recipient change
Fictional message
A fictional message modifies an expected invoice amount, due date, payment recipient, or remittance details.
Pressure
Late-fee threat, final notice, shipment delay, or limited processing window.
Defensive control
Compare the invoice with the purchase order, contract, receiving record, prior invoice, and known vendor confirmation.
Evidence
Invoice record, purchase order, contract, project owner, sender evidence, attachment metadata, and payment system.
Confidential document request
Fictional message
A fictional leader, lawyer, auditor, school official, or vendor asks for protected records through email.
Pressure
Confidentiality, authority, legal urgency, or an instruction to bypass the approved sharing platform.
Defensive control
Verify requester identity, data owner, purpose, minimum necessary information, approval, and trusted sharing method.
Evidence
Data classification, requester relationship, owner approval, legal or business process, sharing logs, and user action.
Account recovery or MFA approval
Fictional message
A fictional support or leadership message asks the recipient to share a code, approve a prompt, or help restore access.
Pressure
Urgent outage, executive travel, locked account, or business interruption.
Defensive control
Use the approved recovery and support workflow and never share authentication codes.
Evidence
Identity-provider events, recovery records, help-desk case, factor changes, sessions, device evidence, and owner confirmation.
Reply-chain payment diversion
Fictional message
A fictional message appears inside an existing invoice or project conversation and introduces new payment details.
Pressure
Continuity, familiarity, real project context, and an urgent final change.
Defensive control
Compare prior participants, domains, reply paths, message IDs, attachment history, and known vendor contacts.
Evidence
Conversation thread, sender changes, reply path, authentication, prior invoices, vendor confirmation, and account activity.
Shared-mailbox impersonation
Fictional message
A fictional message claims to come from finance, payroll, support, admissions, purchasing, or another shared function.
Pressure
Routine administrative language, expected branding, and a request framed as standard process.
Defensive control
Verify through the known shared mailbox, portal, ticketing system, or department process.
Evidence
Shared-mailbox membership, sending service, message trace, ticket record, process owner, and user report.
Impersonation Models
Eight Sender Scenarios That Require Different Conclusions
Display-name impersonation
Fictional example
The fictional inbox shows a known executive name while the actual address belongs to an unrelated domain.
Strongest evidence
Display name, actual address, domain, message purpose, and independent executive-office confirmation.
Limitation
A display-name mismatch supports impersonation but does not identify the physical sender.
Lookalike-domain impersonation
Fictional example
A fictional vendor name appears with a domain that adds a hyphen or payment-related word.
Strongest evidence
Exact domain comparison, authentication for the lookalike domain, vendor records, and known-contact verification.
Limitation
The lookalike domain may authenticate perfectly for itself.
Direct spoofing
Fictional example
A fictional message claims the trusted domain but fails aligned authentication and is not confirmed by the owner.
Strongest evidence
Visible From domain, SPF, DKIM, DMARC, routing, policy result, and owner confirmation.
Limitation
Forwarding and misconfiguration can sometimes produce authentication failure.
Compromised legitimate mailbox
Fictional example
A fictional message comes from a real vendor account, passes authentication, but requests an unusual bank change.
Strongest evidence
Known domain, aligned authentication, account activity, unusual request, business-process mismatch, and vendor confirmation.
Limitation
Authentication alone cannot show whether the authorized mailbox user created the message.
Reply-chain abuse
Fictional example
A fictional message includes real project history but changes the reply address, attachment, or payment instructions.
Strongest evidence
Thread participants, message IDs, domain changes, reply path, prior messages, vendor contact, and transaction records.
Limitation
Conversation content may have been copied, forwarded, or accessed through a compromised account.
Third-party service confusion
Fictional example
A fictional approved platform sends on behalf of an organization using different transport infrastructure.
Strongest evidence
Service owner, approved relationship, aligned identity, message purpose, prior history, and business confirmation.
Limitation
Different infrastructure is not automatically impersonation.
Personal-mailbox request
Fictional example
A fictional leader claims their work email is unavailable and asks the recipient to continue through a personal account.
Strongest evidence
Known-contact verification, organization policy, account status, request type, and business owner confirmation.
Limitation
Rare emergencies can exist but still require approved alternative verification.
Shared-function impersonation
Fictional example
A fictional message claims to be payroll or finance but is not connected to the approved shared mailbox or ticketing system.
Strongest evidence
Shared-mailbox records, sending account, message trace, ticket number, department owner, and process evidence.
Limitation
Departments may use approved vendors or automated services that require context.
Core Concept
Separate Sender, Request, Process, Account, and Impact
Sender
Which fictional display name, address, domain, account, Reply-To, and authentication identity sent the message?
Request
Which fictional payment, payroll, data, account, approval, purchase, or recovery action is requested?
Process
Which owners, systems, approvals, known contacts, waiting periods, and separation-of-duties controls should apply?
Account
Which fictional sessions, factors, mailbox rules, forwarding, recovery, device, and owner records explain the sender account?
Impact
Which fictional beneficiary, payment, payroll, data, permission, account, or business state actually changed?
Evidence Matrix
What Business Email Compromise Evidence Can Prove
Evidence source
Sender and domain evidence
Can support
The fictional display name, address, domain, Reply-To, authentication, routing, and known sender relationship.
Limitation
A real domain or mailbox can still be compromised, and a lookalike domain can authenticate itself.
Evidence source
Business-process evidence
Can support
The fictional required approvals, separation of duties, portal, purchase order, invoice, payroll, vendor, or account-change workflow.
Limitation
Processes can include approved exceptions, but those exceptions need accountable documentation.
Evidence source
Transaction records
Can support
The fictional amount, beneficiary, bank account, invoice, purchase order, payment status, approval chain, and timing.
Limitation
A transaction record shows system state but not always why the decision was made.
Evidence source
Conversation history
Can support
The fictional prior messages, participants, domains, message IDs, attachments, requested actions, and expected next step.
Limitation
Real conversation details can be copied or exposed through account compromise.
Evidence source
Identity and session evidence
Can support
The fictional sign-ins, MFA, sessions, devices, recovery, factor changes, mailbox actions, and application activity.
Limitation
Account evidence may not identify the physical person or intent without stronger context.
Evidence source
User and owner reports
Can support
The fictional recipient’s actions and the claimed sender, vendor, payroll, finance, or resource owner’s confirmation.
Limitation
Human statements should be correlated with technical and business records.
Evidence source
Security-control evidence
Can support
The fictional filtering, warning, reputation, authentication, quarantine, link, attachment, and policy results.
Limitation
Tool verdicts are interpretations and can change with new evidence.
Evidence source
Independent verification
Can support
Whether the fictional sender, vendor, employee, invoice, payment change, payroll request, or data request is confirmed through a trusted path.
Limitation
Verification is unreliable if the contact details came from the suspicious message.
Case Classification
Eight Outcomes with Different Evidence Requirements
Expected business request
The fictional sender, domain, account, transaction, timing, purpose, approvals, and independent verification all match the established process.
Required documentation
Record the approved relationship, owners, request, supporting system records, and any remaining limitation.
Unusual but approved exception
The fictional request falls outside the normal pattern but is independently confirmed, time limited, owner approved, and documented.
Required documentation
Record the exception reason, approving owners, scope, duration, controls, verification, and expiration.
Suspicious impersonation attempt
The fictional message uses sender, domain, authority, urgency, secrecy, or process mismatches but no downstream action is confirmed.
Required documentation
Preserve evidence, verify independently, assign owners, contain related messages, and avoid claiming impact without supporting records.
Confirmed business email compromise attempt
The fictional evidence supports impersonation, deceptive account use, unauthorized business instructions, or attempted transaction diversion.
Required documentation
Record sender and account evidence, request, affected recipients, business process, containment, account review, and validation.
Confirmed transaction or data impact
The fictional evidence supports a payment, payroll, beneficiary, data, account, permission, or other measurable business change.
Required documentation
Separate the message finding from each confirmed downstream action and preserve transaction, identity, application, and owner evidence.
Compromised legitimate account suspected
The fictional message authenticates for a real account or domain but the request is unauthorized, unusual, or inconsistent with the owner’s activity.
Required documentation
Preserve mailbox, identity, session, factor, device, thread, and business evidence and begin approved account-recovery review.
False positive or legitimate third-party workflow
The fictional message appears unusual but is supported by an approved service, sender, owner, process, and independent verification.
Required documentation
Explain why it is legitimate, record the approved relationship, and tune controls narrowly if needed.
Evidence incomplete
The fictional sender, account, transaction, user, approval, or business evidence is insufficient for a reliable conclusion.
Required documentation
State the missing evidence, confidence, temporary hold or control, owner, due date, and decision criteria.
Defensive Workflow
Respond to BEC in Six Steps
Pause the sensitive action
Place an approved fictional hold on payment, payroll, data transfer, account change, or other high-impact action while evidence is reviewed.
Preserve message and business evidence
Keep the fictional message, headers, authentication, thread, attachments, links, transaction records, approvals, and user report.
Verify independently
Use a known fictional contact, trusted portal, vendor record, payroll system, directory, purchase order, or established workflow.
Review account and transaction activity
Correlate fictional mailbox, identity, session, factor, application, payment, payroll, document, and approval records.
Contain and remediate narrowly
Quarantine related messages, stop unauthorized changes, restore correct details, revoke unsafe sessions, recover accounts, and notify owners as evidence supports.
Validate and close
Confirm legitimate communication, correct transaction state, account security, owner acceptance, monitoring, residual risk, and closure evidence.
Remediation and Validation
Eight Actions for Coordinated Closure
Maintain the transaction hold
Prevent the fictional payment or beneficiary change while evidence and owner verification are completed.
Owner
Accounts Payable
Validation
Confirm no payment, approval, vendor-master, or bank-account update occurred.
Preserve and search related messages
Identify the fictional recipient, thread, subject, sender, Reply-To, attachment, and request scope.
Owner
Email Security
Validation
Confirm all approved related messages are quarantined and legitimate vendor mail remains available.
Recover the affected vendor account
Restore control of the fictional legitimate mailbox and remove unauthorized sessions, factors, rules, or forwarding.
Owner
Vendor Identity and Email Administration
Validation
Confirm owner access, factor inventory, session state, mailbox rules, sending behavior, and monitoring.
Restore trusted payment instructions
Ensure the fictional vendor master and pending invoices use the independently verified beneficiary details.
Owner
Procurement and Vendor Master Team
Validation
Confirm the correct account, approvals, waiting period, and owner acceptance.
Notify affected recipients
Provide a fictional factual notice about the unauthorized request, safe reporting, and independent verification path.
Owner
Security Communications and Finance Leadership
Validation
Confirm recipients understand the correct vendor contact and no one completed the request.
Review similar high-risk changes
Search fictional payroll, invoice, beneficiary, gift-card, data, and account-change workflows for related patterns.
Owner
Security Operations and Business Control Owners
Validation
Document searched systems, time range, findings, gaps, and residual risk.
Improve process and monitoring
Strengthen fictional transaction holds, known-contact verification, mailbox-rule alerts, session alerts, and change approvals.
Owner
Finance Governance, Identity, and Security Monitoring
Validation
Test both legitimate and unauthorized requests and confirm alert routing and owner response.
Close with evidence
Document fictional message, account, transaction, business, containment, recovery, validation, monitoring, and residual-risk evidence.
Owner
Case Owner
Validation
Confirm all technical and business closure criteria are met and approved.
Correlated Case Timeline
Follow a Fictional Vendor Account Compromise from Request to Closure
09:08:03
Conversation
A fictional vendor thread continues a real equipment order and asks that the final invoice be paid to a new bank account.
Creates familiarity through a legitimate project and introduces a high-impact beneficiary change.
09:08:07
Sender identity
The visible sender is billing@trusted-vendor.example and aligned authentication passes.
Supports use of the legitimate vendor domain but does not approve the changed payment request.
09:08:11
Reply path
The fictional Reply-To redirects responses to accounts-update@vendor-billing.example.
Adds an unexpected external reply path not present in earlier thread messages.
09:08:15
Message content
The sender claims the old bank account is unavailable and requests payment before noon to avoid shipment delay.
Adds urgency, financial pressure, and a reason to bypass normal verification.
09:10:00
Purchasing process
The fictional vendor-change policy requires a known-contact call, vendor-master update, two approvals, and a waiting period.
The email request does not satisfy the established control process.
09:12:00
Recipient action
The fictional accounts-payable employee places a transaction hold and reports the message without changing the vendor record.
Prevents immediate financial impact and preserves the request for review.
09:16:00
Independent verification
The known fictional vendor contact confirms that no banking change was requested and that their billing mailbox is under review.
Supports an unauthorized request and possible compromise of a legitimate mailbox.
09:20:00
Account review
The fictional vendor reports an unfamiliar mailbox rule and an unrecognized session created earlier that morning.
Adds evidence supporting compromised-account use rather than direct domain spoofing.
09:24:00
Related-message search
The fictional environment identifies five related messages sent to finance and project staff.
Expands the affected-recipient and transaction scope.
09:28:00
Containment
The related messages are quarantined, the unrecognized vendor session is revoked, and the suspicious mailbox rule is removed through approved response.
Addresses message distribution and the likely account-control issue.
09:35:00
Transaction review
No fictional payment, vendor-master, beneficiary, or approval change is found.
Supports no confirmed financial impact in the reviewed systems.
09:42:00
Recovery
The fictional vendor completes approved password reset, factor review, session revocation, mailbox-rule review, and owner validation.
Restores control of the legitimate account.
Day 2
Validation
Legitimate vendor communication resumes through the known address, the original bank account remains active, and monitoring finds no new related activity.
Completes communication, account, transaction, and monitoring validation.
Key Vocabulary
Business Email Compromise Terms
Business email compromise
A fictional email-based deception or account misuse intended to influence a business, financial, payroll, data, access, or operational decision.
Executive impersonation
A fictional attempt to appear as a leader or authority figure in order to pressure a recipient into acting quickly.
Vendor fraud
A fictional message or account action that changes payment, invoice, shipping, banking, or contact information for a supplier or service provider.
Payroll diversion
A fictional request that attempts to redirect salary, reimbursement, tax, benefit, or direct-deposit information.
Invoice manipulation
A fictional change to the amount, account, recipient, date, or payment instructions associated with an expected invoice.
Reply-chain abuse
A fictional message that appears inside, copies, or continues a real conversation in order to increase trust.
Lookalike domain
A fictional domain designed to resemble a trusted organization while remaining technically separate.
Compromised legitimate account
A fictional real account that may be used by an unauthorized person while still passing normal domain authentication.
Independent verification
Confirmation through a fictional known contact path, approved portal, purchasing record, payroll system, directory, or business workflow not controlled by the suspicious message.
Transaction hold
A fictional approved pause placed on a payment, payroll, purchasing, or account-change request while evidence is reviewed.
Beneficiary change
A fictional modification to the bank account, payment recipient, deposit destination, or other party receiving funds.
Out-of-band confirmation
A fictional verification completed through a separate trusted channel, such as a known phone number, approved system, or in-person process.
Fake Dashboard
Fake Business Email Compromise Review Dashboard
Training dashboard for the fictional Northstar Learning Services finance and email environment.
High-risk requests
24
Vendor changes, payroll updates, invoices, gift cards, protected data, recovery, and confidential executive actions.
Transaction holds
7
Narrow holds preserved time for vendor, payroll, finance, data-owner, and account verification.
Confirmed losses
0
The reviewed fictional cases were contained before confirmed payment, payroll, data, or account impact.
Fake SOC Alert
Authenticated Vendor Mailbox Requests Unauthorized Bank Change
Source: Fake BEC and Transaction Review Console • Time: 09:08 AM
Fake Log Panel
Fake Vendor Payment-Diversion Timeline
09:08:03 THREAD project='equipment_order' request='new_bank_account' 09:08:07 AUTH visible_domain='trusted-vendor.example' result='aligned_pass' 09:08:11 REPLY_TO address='accounts-update@vendor-billing.example' 09:08:15 CONTENT urgency='before_noon' pressure='shipment_delay' 09:10:00 PROCESS required='known_contact,two_approvals,waiting_period' 09:12:00 TRANSACTION_HOLD status='active' vendor_master_changed='false' 09:16:00 VERIFY vendor_request='denied' mailbox_status='under_review' 09:20:00 ACCOUNT finding='unfamiliar_rule,unrecognized_session' 09:24:00 SEARCH related_messages='5' 09:28:00 CONTAIN quarantine='5' session_revoked='true' rule_removed='true' 09:35:00 TRANSACTION_REVIEW payment_change='none' beneficiary_change='none' 09:42:00 RECOVERY password='reset' factors='reviewed' sessions='revoked' DAY2 VALIDATION legitimate_vendor_mail='working' bank_account='unchanged'
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
Which BEC Conclusion Is Best Supported?
Which conclusion is strongest?
Common Mistakes
Mistakes That Weaken BEC Analysis
Safe Practice Lab
Complete a Fictional Business Email Compromise Review
Fictional Evidence Set
Meadowbrook Vendor and Payroll Case
Review thirty-eight supplied fictional records covering sender identities, domains, authentication, reply paths, conversation history, invoices, purchase orders, vendor records, payroll requests, approvals, transaction holds, mailbox rules, sessions, factors, account recovery, user reports, containment, validation, and closure.
Required Analysis
- Identify the fictional BEC pattern and requested business action.
- Compare display name, address, domain, Reply-To, authentication, account, and business identity.
- Map the approved financial, payroll, data, account, or vendor-change process.
- Separate confirmed facts, conclusions, alternative explanations, confidence, and evidence gaps.
- Create an independent verification plan using known contacts and systems of record.
- Review mailbox rules, forwarding, sessions, factors, recovery, recipient actions, and transaction state.
- Recommend transaction holds, quarantine, account recovery, correct-record restoration, notifications, monitoring, validation, and closure.
Scenario Decision Lab
A Real Vendor Mailbox Requests New Banking Details
A fictional message comes from the known vendor domain and passes authentication, but it changes the Reply-To address and asks for a new bank account outside the approved process.
Scenario Decision Lab
An Executive Requests Confidential Gift Cards
A fictional message uses an executive’s name, says the executive is unavailable by phone, asks for gift cards within thirty minutes, and tells the recipient not to discuss the request.
Defender Habits
Business Email Compromise and Impersonation Checklist
Check Your Understanding
I7.5 Mini Quiz: Business Email Compromise and Impersonation
Choose your answers first. Explanations appear only after submission.
1. What is business email compromise?
2. Why can a fictional BEC message pass SPF, DKIM, and DMARC?
3. What is the safest response to a vendor bank-account change?
4. Which evidence most strongly supports a compromised legitimate mailbox?
5. Why should a transaction hold occur before a final conclusion?
6. What is reply-chain abuse?
7. Which closure plan is strongest after a fictional BEC attempt?
Portfolio Prompt
Portfolio Prompt
Create a fictional Business Email Compromise Case Report using at least thirty-eight sender, domain, authentication, Reply-To, conversation, invoice, purchase-order, vendor, payroll, approval, transaction, mailbox-rule, session, factor, recovery, user-report, containment, validation, and closure records. Include the BEC pattern, impersonation type, requested action, business process, transaction hold, evidence matrix, findings, owners, account recovery, verification, residual risk, and closure criteria.
Key Takeaways
What You Should Remember
Navigation