No malware, no link, no attachment. Business email compromise is a conversation: an attacker inside or alongside a real email thread, steering a real payment to the wrong account. It is the attack clients fear most because the loss is immediate, and the one that filters miss most because nothing about the message is technically malicious.
enhanced.io is a channel-only Open XDR SOCaaS built exclusively for MSPs, with 400+ integrations across endpoint, network, cloud, identity and IoT/OT.
The situation
A client's supplier has an email problem they do not know about yet. An attacker has been reading the thread between the supplier's account manager and the client's finance team, learning the invoice cadence, the tone, the amounts. When the next invoice falls due, the attacker registers a domain one character away from the supplier's, and sends the expected invoice from it, with new bank details and a plausible line about a banking change.
The finance user has no reason for suspicion. Right sender name, right thread, right amount, right time of month.
What we detect
The email connector scores the message on what a busy human misses: the sending domain is days old, registered recently, and one character off a domain the client corresponds with daily. Domain age plus lookalike distance plus a finance recipient plus payment-change language is a recognized fraud pattern, and it correlates into a High case before anyone acts on the invoice.
What gets automated
The message is flagged and the lookalike domain is blocked for the tenant, per the posture agreed at onboarding. Nothing else needs automating, because the attack has no technical payload. The job is making sure the right human hears about it before the payment run.
Where humans step in
An analyst confirms the domain registration detail and checks whether the same sender reached anyone else in the tenant. Escalation goes to the MSP with a specific instruction for the client: verify the banking change with the supplier by phone, on a known number, and warn them their thread is being read. The Fractional Security Director follows up with the pattern-level recommendation, usually a payment-verification policy so bank-detail changes always require out-of-band confirmation.
The outcome
The payment goes to the right account. The supplier finds out their mailbox is compromised from a partner instead of a lawsuit. The client gets a payment-verification policy with a story attached, which is the only way finance policies ever stick.
Check your own stack
Would a days-old lookalike domain emailing a client's finance team raise anything?
Do your clients verify bank-detail changes out of band, every time?
Who would an alert like this reach, and how fast, on invoice day?
