M ManySignal

Use Case: Email

Business email compromise

The CFO's account sends wire transfer instructions to AP. The CFO is on vacation and didn't send anything. ManySignal caught the forwarding rule 6 hours earlier.

Attack scenario

$47,000 wired to a bank account in 3 hours

Business Email Compromise is the highest-dollar fraud vector in enterprise security. The FBI's IC3 reports over $2.7 billion in BEC losses annually — more than ransomware. The mechanics are deceptively simple: compromise an executive email account, set up a silent forwarding rule to monitor financial conversations, then at the right moment send instructions to change a wire transfer destination.

The attacker often doesn't need to compromise anything. A lookalike domain — corp0ration.com instead of corporation.com — sends an email from someone who appears to be the CFO. The finance employee, under time pressure, initiates the transfer. The money is gone before anyone realizes the domain was wrong.

Detection requires correlating three distinct signals: account compromise indicators (new IP, suspicious forwarding rule), email content analysis (payment instruction language), and domain lookalike detection. No single tool covers all three.

Detection logic
rule: business_email_compromise
type: correlation + nlp
sources:
  - microsoft_365_audit
  - google_workspace_gmail
  - okta_system_log (account compromise context)
trigger:
  - OR:
    # Scenario A: account compromise + financial email
    - condition: |
        mailbox_rule_created(external_forward) WITHIN 48h
        AND email_sent(nlp_payment_score > 0.85)
    # Scenario B: lookalike domain impersonation
    - condition: |
        sender_domain.levenshtein_distance(company_domains) <= 2
        AND nlp_payment_score > 0.7
enrichments:
  - nlp_payment_classifier: fine-tuned on IC3 BEC corpus
  - domain_lookalike: dnstwist, certstream
  - erp_payment_lookup: sap, netsuite
  - executive_directory: hr_system
mitre: T1566.002 (Phishing: Spearphishing Link), T1534 (Internal Spearphishing)
Triage agent questions
1

Is there a mailbox forwarding rule sending email to an external address added in the past 7 days?

M365 / GSuite audit
2

Did the sender account authenticate from a new IP or country in the last 48 hours?

IdP audit
3

Does the email contain wire transfer instructions or payment detail changes?

NLP classifier
4

Was the email sent from a lookalike domain (typosquat) rather than the legitimate domain?

Domain analysis
5

Has the target recipient responded to BEC-style requests from this sender before?

Email graph
6

Is there a finance workflow (AP/AR) in progress that matches the urgency claimed in the email?

ERP integration
7

Did the account send any emails with wire transfer instructions in the past 30 days?

Email content analysis
Response playbook
1

Flag the email thread in Microsoft 365 Defender and add a warning banner to the email

Autonomous
2

Notify the finance team's security liaison with evidence summary and hold recommendation

Autonomous
3

Quarantine the sender account pending investigation if account compromise confirmed

Approve-gated
4

Remove any mailbox forwarding rules added in the past 7 days from the compromised account

Approve-gated
5

Submit lookalike domain to block list via M365 tenant allow/block list

Autonomous
6

Initiate payment recall process with finance if wire transfer was already initiated

Recommend

Legacy SOC comparison

Email security gateways scan for known malicious links and attachments. BEC emails carry neither — they're clean text with plausible business language. The forwarding rule that silently drains all incoming email to an attacker mailbox creates no security alert in a standard M365 configuration. The SOC finds out about the BEC when the finance team calls the CFO directly and realizes the email wasn't from them.

MITRE ATT&CK mapping

T1566.002 — Phishing: Spearphishing LinkT1534 — Internal SpearphishingT1114.003 — Email Collection: Email Forwarding RuleT1036.005 — Masquerading: Match Legitimate Name

Business email compromise FAQ

Does ManySignal detect vendor email compromise (VEC), not just internal BEC?

Yes. Vendor email compromise is often harder to detect because the email comes from a legitimate vendor domain that has been compromised. ManySignal looks for behavioral changes in the vendor's email patterns — sudden forwarding rules, new sending IP, unusual email content patterns — rather than just checking the domain.

How does the NLP classifier identify payment-related content?

ManySignal's email NLP model is trained specifically on BEC language patterns — urgency cues ('wire must be sent today'), payment instruction changes, executive impersonation language, and financial keyword combinations. The model runs on email body and subject line in the data pipeline before the alert fires.

What's the detection coverage for CEO fraud / whale phishing?

CEO fraud (impersonating an executive to pressure a finance employee) is detected via two signals: domain lookalike analysis for external impersonation, and account behavior changes for internal account compromise. Both patterns trigger the BEC use case workflow.

Can ManySignal integrate with finance systems to verify payment requests?

ManySignal has a read-only integration with SAP, NetSuite, and QuickBooks Online. When a BEC alert fires, the triage agent checks whether an approved payment exists in the ERP that matches the requested amount and vendor — a clean correlation that human analysts rarely have time to do.

Stop BEC before the wire transfer leaves

Email content analysis, account compromise detection, and domain lookalike monitoring — all correlated in one alert.