Business Email Compromise has evolved from a relatively crude social engineering technique into one of the most financially damaging threat categories facing organisations today. While large enterprises command the headlines when BEC campaigns result in multi-million-pound transfers, the small and medium business segment represents a disproportionate share of successful attacks — largely because the defensive posture of most SMBs creates conditions that threat actors have learned to exploit systematically.
This article examines the specific attack patterns used in BEC campaigns targeting SMBs, the detection opportunities available at each stage of the attack chain, and the incident response considerations that differ meaningfully from enterprise environments. The analysis draws on observed attack patterns across the SMB sector, with particular attention to the techniques that bypass commonly deployed email security controls.
Why SMBs Are Disproportionately Targeted
The conventional assumption is that threat actors prefer high-value enterprise targets. In practice, the economics of BEC campaigns favour SMBs for several reasons that are worth understanding before examining the technical attack chain.
First, SMBs typically operate with flat organisational hierarchies and informal approval processes. A finance team member at a 20-person firm will often act on an instruction from the director without the multi-stage approval workflows that exist in larger organisations. The social engineering component of BEC is therefore significantly easier — one convincing impersonation is often sufficient to initiate a fraudulent transfer.
Second, email security controls at the SMB level are frequently limited to basic spam filtering and, in many cases, Microsoft Defender for Office 365 Plan 1 at best. Advanced controls such as attack simulation training, Safe Links, Safe Attachments, and anti-impersonation policies are often absent or misconfigured. DMARC, DKIM, and SPF records, while increasingly common, are frequently deployed in monitoring-only mode rather than enforcement — providing telemetry but no actual protection.
Third, SMBs rarely have a dedicated security operations capability. Alerts generated by Microsoft 365 or third-party tooling are often reviewed intermittently or not at all. Threat actors conducting reconnaissance on a target organisation can frequently identify this gap through analysis of publicly observable signals — response times on LinkedIn, the absence of a security-specific job posting history, and the presence of standard consumer-grade security tooling.
BEC Attack Chain: Stage-by-Stage Analysis
Stage 1: Reconnaissance
BEC campaigns targeting SMBs typically begin with open-source intelligence gathering rather than technical exploitation. Threat actors identify key personnel — finance leads, executive assistants, and directors — through LinkedIn, Companies House filings, and the company website. Email address formats are trivially enumerated given that most SMBs use a small number of standard patterns (firstname.lastname@, firstname@, or initials@).
At this stage, the attacker is building the social context needed to make impersonation convincing. They will review recent press releases, LinkedIn activity, and any publicly available financial information to identify timing opportunities — upcoming invoice cycles, supplier relationships, and any recent organisational changes that create a plausible pretext for an unusual payment request.
Detection opportunity at this stage is limited for the target organisation. However, if you are operating threat intelligence monitoring, indicators to watch include:
- Repeated OSINT queries against your organisation’s LinkedIn profiles from new or recently created accounts
- Enumeration attempts against your email server using SMTP VRFY or RCPT TO probing — visible in mail server logs if you are collecting them
- Registration of lookalike domains within a few days of an organisational announcement or change
Stage 2: Infrastructure Setup
Before initiating contact, the attacker establishes sending infrastructure designed to pass technical email authentication checks or to impersonate the target organisation at the display name level. The two most common approaches in SMB-targeted BEC campaigns are:
Display name spoofing — The attacker registers a free email account (Gmail, Outlook.com) and sets the display name to match the impersonated executive. No domain spoofing occurs, so SPF and DKIM checks pass. The attack relies entirely on the recipient reading only the display name rather than the full From address. This remains effective because most email clients in mobile view display only the name by default.
Lookalike domain registration — A visually similar domain is registered (e.g. oceant3le.com, ocean-tele.com, oceantele.co) and configured with valid SPF, DKIM, and DMARC records. The sending domain passes authentication checks, and without specific anti-impersonation rules tuned to your domain’s lookalikes, most email security controls will not flag it. Free hosting providers allow rapid domain and mailbox setup with minimal attribution.
Detection at this stage is possible if you are monitoring for lookalike domain registrations. Tools such as dnstwist can enumerate potential lookalikes and be scheduled to alert on new registrations. MITRE ATT&CK T1583.001 (Acquire Infrastructure: Domains) covers this technique.
# Example dnstwist command for monitoring lookalike domain registrations
dnstwist –registered –format csv oceantele.com | grep -v ‘original’
# Schedule weekly and alert on new entries — pipe to SIEM or alerting platform
Stage 3: Initial Contact and Pretext Establishment
The first email in a BEC campaign is rarely the payment request itself. Sophisticated threat actors establish a plausible interaction before making the fraudulent request — a technique that significantly increases success rates by creating the appearance of an ongoing legitimate conversation.
Common initial pretexts include:
- An executive requesting a quick call or asking whether the target is available — establishing rapport before escalating to a payment request
- A supplier notification that banking details have changed, sent as a precursor to a follow-up invoice
- A request for an invoice to be processed urgently due to an audit, end-of-month deadline, or board requirement
At this stage, detection depends on whether your email security controls are configured to flag display name impersonation and lookalike domain sending. Key detection rules to implement in Microsoft Defender for Office 365 or your SIEM include:
// Anti-phishing policy — impersonation protection
// Enable: EnableMailboxIntelligenceProtection = True
// Enable: EnableSimilarDomainsSafetyTips = True
// Configure: TargetedUsersToProtect — include executives, finance leads
// Configure: TargetedDomainsToProtect — include your primary domain
In Microsoft 365 environments, the Unified Audit Log will record email receipt events, including the sending domain and full From header. Correlating display name against the actual sending domain for any email matching executive names is a high-value detection rule that generates low false positives in most SMB environments.
Stage 4: The Payment Request
Once the pretext is established, the fraudulent payment request follows. In SMB-targeted campaigns, this is typically a direct request for a BACS transfer, a change of bank details on an existing supplier, or an instruction to process an invoice urgently. The request will usually include a reason that explains the urgency and the absence of the normal process — a board decision made at short notice, a supplier threatening to suspend service, or a confidentiality requirement that prevents the request from going through the usual channels.
The specific social engineering elements are tuned to the target based on the reconnaissance conducted in Stage 1. A firm in the middle of a property transaction, for example, may receive a request that references the transaction specifically — a technique known as spear-phishing within BEC campaigns, or in the context of property transactions, Friday afternoon fraud.
Detection at this stage should focus on the content of the email rather than its technical headers. Natural language processing rules in modern email security platforms can flag emails containing high-risk combinations of terms — urgent payment requests, bank detail changes, requests for confidentiality — particularly when combined with an external sender displaying an internal name. The following KQL query can be used in Microsoft Sentinel to surface these patterns:
EmailEvents
| where SenderFromDomain != ‘oceantele.com’
| where SenderDisplayName has_any (‘Director’, ‘CEO’, ‘MD’, ‘Finance’, ‘Accounts’)
| where Subject has_any (‘urgent’, ‘payment’, ‘transfer’, ‘bank’, ‘invoice’, ‘confidential’)
| project Timestamp, SenderFromAddress, SenderDisplayName, RecipientEmailAddress, Subject
| order by Timestamp desc
The Role of the Managed IT Provider in BEC Defence
The detection and prevention controls described above require ongoing configuration, monitoring, and tuning. In an enterprise environment with a dedicated SOC, this is achievable with in-house resources. In an SMB environment, it typically is not, which is where the managed IT provider becomes a critical component of the organisation’s security posture.
A managed IT provider with genuine cybersecurity capability should be implementing and monitoring the following controls as standard for SMB clients:
- DMARC enforcement (p=reject) on the primary domain — not monitoring mode
- Anti-impersonation policies in Microsoft 365 covering named executives and finance personnel
- Lookalike domain monitoring with alerting on new registrations
- Unified Audit Log retention is configured to at least 90 days — the default 30-day retention is insufficient for most incident investigations
- Multi-factor authentication is enforced on all mailboxes — conditional access policies rather than per-user MFA, which can be bypassed
- Regular attack simulation campaigns targeting finance and executive staff specifically
The gap between what is technically possible and what most SMBs actually have deployed is significant. Many organisations have Microsoft 365 subscriptions that include Defender for Office 365 Plan 1, but have never configured the anti-phishing or anti-impersonation policies within it. The controls exist but are inactive, providing no protection against the attack patterns described above.
Incident Response Considerations for SMB BEC
When a BEC attack succeeds — and a proportion will, regardless of the controls in place — the incident response process in an SMB environment differs from enterprise in several important ways.
Containment
The immediate priority when a fraudulent payment is identified is to contact the sending bank and the receiving bank as quickly as possible. The UK’s Faster Payments system processes transactions within seconds, but banks have fraud recall procedures — the success rate for recovery depends heavily on how quickly the fraud is reported. Simultaneously, the compromised or impersonated account should be isolated and the organisation’s IT provider notified to preserve logs before they are overwritten.
Evidence Preservation
In SMB environments, the Unified Audit Log is frequently the primary source of forensic evidence. Preserving the log before any remediation actions are taken is critical — account resets, mailbox deletions, and policy changes can all affect what remains available for investigation. If the attack involved account compromise rather than pure social engineering, reviewing the Azure AD Sign-in Logs for unusual authentication events — particularly from unfamiliar IP ranges or countries — will establish the scope of the compromise.
// Azure AD sign-in log query — identify anomalous authentication
SigninLogs
| where UserPrincipalName == ‘[email protected]’
| where TimeGenerated > ago(30d)
| where ResultType == 0 // Successful sign-ins only
| project TimeGenerated, IPAddress, Location, AppDisplayName, DeviceDetail
| order by TimeGenerated desc
Notification Obligations
If the BEC attack resulted in the exposure of personal data — for example, if the attacker accessed a mailbox containing client information — the organisation may have a notification obligation under UK GDPR within 72 hours of becoming aware of the breach. The Information Commissioner’s Office provides clear guidance on what constitutes a reportable breach. This assessment should be made early in the incident response process, not as an afterthought.
Summary: Detection and Prevention Checklist
For SOC analysts and IT security professionals supporting SMB environments, the following controls represent the highest-value interventions against BEC campaigns targeting this sector:
- Enforce DMARC at p=reject on all owned domains — monitor-only provides telemetry but no protection
- Configure anti-impersonation policies in Microsoft 365 Defender — name all C-suite and finance personnel as protected users
- Deploy lookalike domain monitoring using dnstwist or a commercial equivalent — alert on new registrations weekly
- Set Unified Audit Log retention to 90 days minimum — extend to 180 days if your licensing permits
- Enforce MFA via conditional access policies on all mailboxes — per-user MFA has known bypass paths
- Run quarterly attack simulation campaigns targeting finance and executive staff — measure and track click rates
- Implement a verbal verification requirement for all payment requests above a defined threshold — the simplest and most effective control of all
BEC is not a technically sophisticated attack. Its effectiveness against SMBs comes from the gap between the controls that are technically available and the controls that are actually deployed and monitored. Closing that gap — consistently and systematically — is the core of effective BEC defence in this segment.
Author Bio
This article was contributed by Ocean Telecom, a managed IT support and cybersecurity specialist based in Oswestry, Shropshire. Ocean Telecom provides managed IT support, cybersecurity monitoring, Microsoft 365 management, and business telecoms to organisations across Shropshire, North Wales, and the wider UK. Visit oceantele.com for more information.