iCloud Calendar Abused to Send Phishing Emails from Apple’s Servers

Attackers are creating iCloud Calendar events whose Notes/DESCRIPTION field contains a classic refund/billing lure (e.g., fake \$599 PayPal charge) plus a “call us” number. They invite a Microsoft 365 address that’s a forwarding list, so Apple’s servers send the calendar invite, and Microsoft’s SRS preserves SPF alignment when it gets forwarded. Result: the email shows From: [email protected] with SPF, DKIM, DMARC all passing; many gateways and users treat it as trusted. Calling the number leads to callback social engineering and potential remote-access malware/financial theft.

Why it’s hard to block:

Authentic infrastructure: Source IP 17.23.6.69 is in Apple’s 17.0.0.0/8 network; DKIM=pass, DMARC=pass for `email.apple.com`. Gateways often soften inspection when major brands fully authenticate.
Forwarding resiliency via SRS: Microsoft 365 rewrites the envelope sender on forwarded mail (not the visible header), so SPF keeps passing after list forwarding.
Legitimate feature abuse, not an exploit: It’s a normal iCalendar (RFC 5545) invite with METHOD\:REQUEST and phishing text in the DESCRIPTION (Notes). No vulnerability required.

What’s actually happening (annotated)

Observed message traits:

Visible sender: `[email protected]`
Authentication-Results example:

spf=pass (sender IP is 17.23.6.69)
smtp.mailfrom=email.apple.com;
dkim=pass (signature was verified) header.d=email.apple.com;
dmarc=pass action=none header.from=email.apple.com;

Body content carried in the iCloud Calendar invite (Notes/DESCRIPTION) with a callback number (e.g., +1-786-902-8579) and a fake PayPal charge (\$599).
Target recipient: a Microsoft 365 address (likely a mailing list) that forwards to many recipients; Microsoft 365 applies SRS so Return-Path shows an SRS-rewritten value while the visible From: remains Apple.

Why the signals are green:

SPF authorizes Apple IPs to send for `email.apple.com` (the envelope MAIL FROM).
DKIM cryptographically ties the message to `email.apple.com`.
DMARC aligns the visible From: with at least one passing mechanism, so it passes. (SPF: RFC 7208; DKIM: RFC 6376; DMARC: RFC 7489).

About Apple IP 17/8: The sender example 17.23.6.69 sits in Apple’s long-held 17.0.0.0/8 allocation (ARIN/Apple guidance), so IP reputation alone won’t flag it.

About the calendar format: The payload is a standard iCalendar object per RFC 5545; the DESCRIPTION (aka “Notes”) is simply text and can contain phone numbers, URLs, or scare-copy. Nothing exotic—just a trustworthy wrapper.

Threat model & kill chain

Setup — Attacker creates an iCloud Calendar event; puts lure text + callback in DESCRIPTION (Notes).
Targeting — Invites a Microsoft 365 list (e.g., `[email protected]`) so Apple’s system sends the invite email.
Delivery — Email originates from Apple, passes SPF/DKIM/DMARC; after list forwarding, SRS retains SPF pass.
Social engineering — Victim calls; attacker escalates to remote-access “refund” support flow → risk of funds theft/malware/data exfiltration.

What doesn’t work well

Blocking by sender domain/IP: `apple.com` + 17/8 are legitimate; you’ll break real Apple traffic. ([whois.arin.net][2])
Relying solely on DMARC/SPF/DKIM: These prove authenticity of the sender domain, not legitimacy of the content. (That’s by design in the RFCs.)
Attachment-only inspection: Not all calendar invites are attachments (`.ics`); many are inline with `Content-Type: text/calendar`, so “attachment-content” rules can miss them. (Use header/content checks too.)

Pragmatic defenses

> Aim for context-aware detections that target calendar messages with financial/urgent callback language, not “Apple” as a brand.

1) Mail flow rules that target calendar content

Condition: Message header includes `Content-Type` with `text/calendar` (or matches pattern `text/calendar`).
AND: Message body or headers include words/patterns like `PayPal`, `charged`, `refund`, `call`, currency amounts, or phone numbers.
Action: prepend a warning, add high-risk SCL, or quarantine for moderation.

Microsoft 365 supports message-header predicates and regex in rules; use them to key off `Content-Type` and suspicious phrases.

Example (conceptual) rule logic

If `A message header includes` → Header name: `Content-Type` → Value contains `text/calendar`
And `The subject or body matches` → regex set (see below)
Then → Quarantine or prepend banner

Regex snippets

US phone numbers (+1 optional), allow separators/spaces

(?i)\b(\+?1[\s\-\.]?)?$?\d{3}$?[\s\-\.]?\d{3}[\s\-\.]?\d{4}\b

Urgent payment/cancellation lexicon

Currency amounts like $599.00

(?i)\$\s?\d{2,4}(\.\d{2})? ```

> Tip: Keep a separate allow-list exception only for known calendar partners to limit false positives.

2) Inspect attachments and inline calendar parts

Where invites are `.ics` files, you can still use attachment inspection in Exchange Online; but also add header/body rules so inline invites are covered. (See attachment inspection & predicates docs.)

3) Advanced Hunting (Defender for O365/M365)

Hunt for calendar messages with callback indicators.

KQL (illustrative)

EmailEvents
| where Timestamp > ago(14d)
| where SenderFromDomain =~ "email.apple.com" or NetworkMessageId in (
EmailHeaders
| where Name =~ "Content-Type" and tostring(Value) contains "text/calendar"
| distinct NetworkMessageId
)
| extend hasCallbackPhone = iff(Subject has "call", true, false)
| summarize count(), any(Subject), any(SenderFromAddress) by RecipientEmailAddress
| order by count_ desc

> Swap in body inspection via `EmailUrlInfo`/`EmailAttachmentInfo` joins where available, or use `EmailHeaders` to key on `Content-Type`. (Field availability varies by license/telemetry tier.)

4) User-experience hardening

Banner external calendar messages and teach users “DMARC pass ≠ safe.”
Optional (high-risk groups): Turn off auto-processing of meeting requests so invites aren’t silently added; users must accept manually, improving scrutiny. (Outlook setting under File → Options → Mail → Tracking). ([Microsoft Support][10])

5) SOC playbook (callback phish)

Contain: Block the callback number at voice gateways; add to TI.
Hunt: Search for the number in mail & chat, and for remote-tool beacons post-call.
Notify: Targeted users; emphasize do not call unsolicited numbers.
Eradicate: Remove invites, revoke any installed remote tools, reset creds if screen-sharing occurred.

Technical appendix

A) Why this survives forwarding

Sender Rewriting Scheme (SRS) in Microsoft 365 rewrites the P1 (envelope) MAIL FROM when a message is forwarded externally, preserving SPF when the forwarder sends on someone’s behalf. The P2 (visible From:) stays as the original (Apple), so DMARC still aligns.

Observed in the wild:

Original Return-Path: [email protected]
Rewritten Return-Path: bounces+SRS=...@<tenant>.onmicrosoft.com

B) iCalendar anatomy you can key on

Core elements from RFC 5545 (typical malicious invites will have these):

BEGIN:VCALENDAR
METHOD:REQUEST
BEGIN:VEVENT
SUMMARY: <often a fake order/charge>
DESCRIPTION: <lure text with phone # or link>
ORGANIZER;CN=<iCloud user>:mailto:<...>
ATTENDEE;CN=<list or target>:mailto:<...>
END:VEVENT
END:VCALENDAR

Focus your rules on `Content-Type: text/calendar`, `METHOD:REQUEST`, and DESCRIPTION keywords.

C) Why email auth won’t save you

SPF authorizes the sending server for the envelope domain.
DKIM attests message integrity & signer domain.
DMARC checks alignment of visible From: with SPF/DKIM results and applies a sender-published policy.

None of these assess message intent; a legit sender can send malicious content (abuse).

Indicators (from the report; rotate fast in practice)

Sender/Domain: `[email protected]`
Auth-Results: `spf=pass` (IP like 17.23.6.69), `dkim=pass` (`d=email.apple.com`), `dmarc=pass`
Lure keywords: “PayPal”, “\$599”, “refund”, “call/support”
Callback example: `+1 (786) 902-8579`

Treat these as patterns, not fixed IOCs.

Step	Risk Factor	Your Defensive Action
1⃣	iCloud Calendar invite with purchase notification in Notes	Treat unexpected invites with high suspicion
2⃣	From email appears to be legitimate Apple address	Don’t trust just the sender—analyze content and context
3⃣	Microsoft 365 forwarding preserves deliverability & authenticity	Recognize SRS behavior but focus on suspicious content
4⃣	Callback phishing leads to remote access/malware installation	Never install tools or provide access based on such calls

This method combines the trust in Apple’s email infrastructure with Microsoft 365's SRS mechanism to create phishing messages that appear both legitimate and technically authenticated. It’s a step beyond usual phishing tactics, blending familiarity with advanced email spoofing to successfully bypass defenses.