Fifty-one images. Not links. Not URLs. Fifty-one base64-encoded PNG blobs stuffed inside a single .ics calendar attachment, invisible to every URL scanner and text-based detection engine in the delivery path.
The email arrived at a corporate sustainability team's mailbox carrying a subject line about an annual standards update. The body was nearly empty: just an external sender warning, a Microsoft logo, and a calendar file named after the recipient's own organization weighing in at 86 KB. That file size is the tell. A normal calendar invite with a title, time, and location runs under 2 KB. This one was 40 times heavier because the HTML description field was packed with inline image data, and the ORGANIZER and ATTENDEE fields were rigged to harvest replies.
Traditional email security inspects three things: sender reputation, URL destinations, and attachment file types. This attack sidestepped all three.
The .ics attachment embedded 51 data:image/png;base64,... blobs directly in the X-ALT-DESC (HTML description) field of the VEVENT. These are not external URLs. They resolve locally inside the calendar client's rendering engine, meaning no scanner can follow a link, detonate a page, or check a domain. The images can render anything: fake login forms, impersonated branding, fabricated documents, or content designed to manipulate the recipient visually. They can also carry steganographic payloads that embed instructions or exfiltration channels inside image pixel data.
This maps to MITRE ATT&CK T1566.001 (Phishing: Spearphishing Attachment). The .ics file is the delivery vehicle, and the 51 inline images are the payload that evades content inspection.
The second mechanism was subtler. The ORGANIZER field was set to mailto:calendar@, making the invite appear to originate from the target organization's own calendar system. The ATTENDEE field referenced the actual recipient. When a user interacts with this invite (accept, decline, tentative), their calendar client sends a response to that ORGANIZER address. If the attacker controls the address or monitors bounces, they confirm the mailbox is active. Even without control, the interaction can trigger out-of-office replies, non-delivery receipts, or auto-accept behaviors that leak scheduling data and internal directory information. This is reply harvesting baked directly into the calendar protocol.
The SOC analysis also flagged the string "ssn" appearing in the attachment's descriptive text, a potential social engineering keyword planted to prime the recipient for sensitive data disclosure.
The sender infrastructure tells a story of opportunistic impersonation built on weak authentication enforcement.
The From header showed nigel@nigelspalding[.]com with a display name of "Assurance Manual." The email body and .ics attachment branded themselves as a different corporate entity entirely. This sender-brand mismatch is a core social engineering signal: the sender's identity and the content's claimed identity are two different organizations. It maps to MITRE ATT&CK T1036.005 (Masquerading: Match Legitimate Name or Location).
The originating IP was 192[.]169[.]7[.]55, with a reverse DNS record of server5[.]bestcoffeandounts[.]online. That PTR (note the typo: "coffeandounts" instead of "coffee and donuts") is characteristic of disposable or compromised hosting infrastructure. This aligns with MITRE ATT&CK T1583.001 (Acquire Infrastructure: Domains), where attackers acquire cheap, low-reputation hosting for single campaigns.
At the first relay hop, SPF failed. The IP 192[.]169[.]7[.]55 is not authorized to send for nigelspalding[.]com. But the message then traversed Microsoft protection infrastructure (AMS0EPF000001B4.mail.protection.outlook.com), which accepted, processed, and re-signed it. At the next hop, SPF passed because the Microsoft relay IP (2a01:111:f403:c201::3) was authorized. DKIM was applied by nigelspalding[.]onmicrosoft[.]com, and ARC signatures passed at subsequent hops.
See Your Risk: Calculate how many threats your SEG is missing
This is authentication laundering. The original submission failed SPF, but Microsoft's infrastructure re-signed the message, producing clean authentication results at every downstream check. The Microsoft Digital Defense Report 2024 documents the scale of this problem: threat actors increasingly route mail through legitimate cloud infrastructure specifically to inherit clean authentication signals.
The sending domain's DMARC policy was p=none, which means the domain owner is monitoring authentication failures but not enforcing them. In practical terms, even when SPF fails and DKIM is absent at the originating hop, receiving servers take no protective action. The Verizon DBIR 2024 found that phishing remains the initial access vector in over 30% of breaches, and unenforced DMARC policies are a recurring enabler. The FBI IC3 2024 report further documented business email compromise losses exceeding $2.9 billion, with email authentication gaps as a contributing factor.
| Type | Value | Context |
|---|---|---|
| Domain | nigelspalding[.]com | Sender domain, personal, DMARC p=none |
| nigel@nigelspalding[.]com | From address | |
| IP | 192[.]169[.]7[.]55 | Originating IP, SPF fail |
| PTR | server5[.]bestcoffeandounts[.]online | Reverse DNS of originating IP |
| File | [Recipient Org] Guide.ics | Calendar attachment, 86,795 bytes |
| SHA256 | b47b87a01c31c9d3ad5ca660c321adfdf5c0206bc4519ad3c022ea4bf0b45553 | .ics file hash |
| DKIM | nigelspalding[.]onmicrosoft[.]com (selector2) | Microsoft relay-applied DKIM |
| Display Name | "Assurance Manual" | Sender display name |
IRONSCALES Adaptive AI flagged this message through multi-signal correlation: the sender-brand mismatch between the From domain and the body branding, the original SPF failure masked by relay re-signing, the anomalous .ics file size indicating embedded content, and the DMARC enforcement gap. Traditional SEG configurations that stop at authentication pass/fail miss the behavioral pattern entirely.
Calendar .ics phishing is an underreported vector that exploits gaps in how security tools handle non-email content types delivered through email. Here is what to prioritize.
Inspect .ics content, not just file type. Calendar attachments should be parsed for embedded data URIs, oversized HTML descriptions, and ORGANIZER/ATTENDEE fields that reference victim domains. A .ics file with 51 inline images is not a meeting invite.
Treat relay-laundered authentication as suspicious. An SPF fail at the originating hop followed by an SPF pass at a relay hop is not the same as a clean send. Your detection stack should evaluate the full relay chain, not just the final authentication result.
Enforce DMARC. A p=none policy is a monitoring tool, not a security control. Organizations publishing p=none are advertising to attackers that spoofed and misaligned mail from their domain will be delivered without consequence. Move to p=quarantine or p=reject. IRONSCALES DMARC management provides the visibility to make that transition safely.
Monitor for reply-harvesting signals. Any calendar invite where the ORGANIZER mailto address matches the recipient's own domain, but the email's From address is external, should trigger elevated scrutiny. The mismatch between "who sent it" and "who the calendar says organized it" is the detection surface.
The attacks that bypass your URL scanners are not using URLs. They are using calendar protocols, base64 data, and mailto fields. If your detection strategy requires a malicious link to trigger, this is the gap.