Business email compromise targets a trusted business process, often to redirect money or sensitive information. It can use a compromised mailbox, impersonation or a deceptive domain, and may contain no malware at all.
What it is
BEC is a fraud pattern that abuses the credibility of business communication. The attacker seeks a consequential action: changing bank details, paying a false invoice, transferring funds or releasing sensitive records. The message may look routine because the attack is designed around an existing relationship or approval process.
The term does not require a particular technical entry point. An attacker may impersonate an executive, register a confusingly similar domain or use a compromised mailbox. Understanding the actual mechanism matters because securing a mailbox will not remove a fraudulent supplier entry already added to a payment system.
How it works
The attacker introduces or alters an instruction within a trusted workflow. A request may claim urgency, confidentiality or a change in supplier arrangements. If the recipient relies on the message itself as proof of authority, the attacker can redirect the business action without exploiting the finance application’s code.
Conversation context can increase credibility
A compromised account may expose earlier correspondence, making a fraudulent request fit the timing and language of a real transaction. A reply inside a familiar thread is therefore not conclusive evidence of legitimacy. Verify material changes through a channel established independently of the suspicious request.
Technical and process controls interact
Mail authentication and account security reduce some paths, while payment verification and separation of duties address the business decision. Neither layer is sufficient alone. A correctly authenticated message from a compromised supplier can still request an unauthorized bank-account change.
Technical references: FBI · Business email compromise · CISA · Phishing Guidance
How attackers use it
The attacker exploits a gap between apparent authority and verified authority. They may seek a direct transfer or a change that affects later legitimate payments. They may also request employee or customer information that supports another fraud or access attempt.
The key defensive question is what changed in the business process and who independently approved it. A message’s visual quality or absence of a malicious attachment does not answer that question. Fraud can occur entirely through ordinary communication and normal application functions.
Warning signs
Review unexpected bank-detail changes, pressure to bypass approval, requests for secrecy and a new contact channel introduced within an urgent message. Unusual mailbox rules, unfamiliar account sessions or unexplained changes to recovery settings can be relevant when a real account may be compromised.
Do not rely on one signal
A changed domain is worth checking, but an unchanged domain is not proof of safety. A senior sender’s display name is not verified authority. A legitimate invoice number can be copied from real correspondence. Combine transaction verification with technical evidence rather than treating any one visual clue as decisive.
Business impact
BEC can cause direct financial loss, disclosure of sensitive information and disruption of supplier relationships. Recovery may depend on how quickly the organization identifies the transaction and contacts the relevant institutions. Technical containment and financial response need to proceed together.
The incident can also reveal a broader process weakness. If one person can accept an emailed change and release a payment without independent verification, the organization may remain exposed even after the immediate account is secured.
Prevention and remediation
Require independent confirmation of payment-detail changes through trusted contact records. Use separation of duties for consequential transactions and maintain a clear escalation path for unusual requests. Protect mail accounts and recovery methods with strong authentication and monitor relevant account activity.
Incident review
- Establish which instruction, record or payment changed and when. - Contact finance, the financial institution and responders through trusted channels. - Preserve messages, account events and transaction records. - Secure affected accounts and review sessions, forwarding rules and access grants. - Check pending payments and supplier records for related changes. - Correct the approval process and verify that the same path cannot be repeated.
Avoid assuming that a password reset reverses the business impact. The altered payment instruction or disclosed information may persist outside the account. Closure needs evidence addressing both the technical access and the consequential business action.
How Ariema detects or handles it
Ariema can provide context about domains, DNS, certificates, mail policy and public web relationships associated with a suspicious communication. This may help reviewers understand infrastructure changes or an unfamiliar destination.
Ariema’s documented capabilities do not include verifying bank instructions, reading mailbox conversations or determining payment fraud. Finance controls and mail or identity investigations supply that evidence. External infrastructure observations can support those teams without being presented as a complete BEC detection system.
Common questions
Must the attacker compromise a real mailbox?
No. Some schemes rely on impersonation or lookalike domains. Others use a genuinely compromised account or conversation thread.
Will DMARC stop every BEC attempt?
No. Domain authentication policy can address certain spoofing paths, but it does not prevent abuse of a compromised legitimate account or a separately registered deceptive domain.
What matters most after a suspected fraudulent transfer?
Rapidly contact the responsible financial institution and internal response team through established channels, preserve the evidence and follow the relevant reporting process. Do not assume recovery is guaranteed.
Sources & further reading
Primary technical references for this guide. Scenarios are illustrative; they are not customer observations.
FBI · Business email compromiseCISA · Phishing GuidanceNIST SP 800-61 Rev. 3 · Incident Response