ctipilot.ch

Ghost-Sender

campaign · campaign:ghost-sender-exchange-online-spoofing

Exchange Online inbound spoofing bypassing SPF/DKIM/DMARC on third-party-MX tenants; no patch available.

Coverage timeline
1
first 2026-06-10 → last 2026-06-10
Peak priority
high
1 high
Sources cited
3
3 hosts
Sections touched
1
active-threats
Co-occurring entities
0
no co-occurrence
ATT&CK techniques
0
no mapped behavior yet

Hunting pivots

Story timeline

  1. 2026-06-10"Ghost-Sender": Exchange Online accepts spoofed inbound mail bypassing SPF/DKIM/DMARC when a third-party MX fronts the tenant — no vendor patch
    active-threats

Where this entity is cited

  • active-threats1

Source distribution

  • gbhackers.com1 (33%)
  • labs.infoguard.ch1 (33%)
  • security-hub.ncsc.admin.ch1 (33%)

explore in graph

Entries about Ghost-Sender (1)

2026-06-10 · view entry permalink →

HIGH

"Ghost-Sender": Exchange Online accepts spoofed inbound mail bypassing SPF/DKIM/DMARC when a third-party MX fronts the tenant — no vendor patch

Swiss security firm InfoGuard Labs disclosed "Ghost-Sender" on 9 June, a configuration-layer email-spoofing weakness affecting Microsoft 365 tenants whose published MX record points to a third-party gateway (Barracuda/Proofpoint/Mimecast) rather than Microsoft (InfoGuard, 2026-06-09). When inbound filtering is enforced only on the MX path, an attacker who knows the target domain can connect directly to the tenant's *.mail.protection.outlook.com endpoint and relay messages that present as any internal or external sender; because the delivery originates from Microsoft IP space, SPF passes, DKIM has no mismatched signature to fail on, and DMARC is evaluated favourably — the spoofed mail lands in the inbox, in some cases rendering the impersonated internal user's profile picture (NCSC-CH, 2026-06-09). InfoGuard reports that across its bug-bounty sample over 20% of Exchange Online domains were exploitable and roughly half of external-MX deployments lacked the mitigation; Microsoft characterised the behaviour as a known architectural limitation and has not shipped a platform fix, while NCSC-CH issued its own advisory and Microsoft Support confirmed active abuse (NCSC-CH, 2026-06-09). This is a configuration issue (no CVE), enabling high-fidelity BEC and internal-sender impersonation against any organisation on the affected architecture.

Why it matters to us: the EXO-plus-external-filter topology is the dominant Microsoft 365 model in Swiss and EU public-sector environments, and there is no patch — mitigation is configuration. Add an inbound connector of type "Partner"/"On-premises" that requires the gateway's pinned TLS certificate or approved IP ranges, and a priority-0 transport rule that quarantines or rejects inbound mail not arriving via the approved external-filter connector; ensure Enhanced Filtering for Connectors (skip-listing) is configured so EXO evaluates the true originating IP. Hunt in Message Trace for mail received on the Default Frontend connector rather than the expected partner connector.

threat10 Jun 05:00Zmulti-sourceOpen finding ↗