The Partner Invite That Used the Wrong Sending Domain

The invite looked like a routine channel partner follow-up. Subject line: "Ironscales - Partner Webinar - ANZ Distribution." The sender appeared to be someone at an Australian distribution company reaching out after a recent webinar. Attached calendar object. Zoom link. A brief professional note referencing a prior conversation, with a proposed time accommodating Australian time zones.

One of three IRONSCALES employees targeted would have opened this and seen, in the organizer field, the name of a colleague. A real name. A real email address. The kind of B2B meeting request that looks completely routine when your team regularly conducts partner webinars and distribution calls.

The Name That Made It Plausible

The attack worked by exploiting a gap that most people, and most security tools, never think about: the difference between who sent an email and who the calendar says organized the meeting.

The email was sent from an Australian commercial domain. Authenticated. SPF passed. DKIM passed. ARC passed. The mail infrastructure was legitimate, and the cryptographic checks all came back clean. Nothing about the transport layer raised a flag.

But the calendar metadata told a different story. The ORGANIZER field in the .ics object displayed the name and email address of an IRONSCALES employee. Not a generic display name trick, not a lookalike domain with a similar-sounding address. An actual person's identity, inserted into the calendar layer of the message where authentication doesn't reach.

The body reinforced the illusion. It posed as a reply to a prior outreach, written in the voice of the named IRONSCALES employee, addressing the Australian recipient by first name and referencing their ANZ distribution business. It described familiarity with the recipient's vendor stack, alignment with IRONSCALES products on email security, and an interest in exploring a partnership. The signature block included the name, title (Vice President, Global MSP Channels), email, and website. A Calendly booking link. A product feedback survey link. The entire infrastructure of a normal business email.

The Zoom meeting was real, in the sense that the link was a legitimate Zoom URL, the Meeting ID and passcode were valid format, and the one-tap phone numbers were Australian dial-in numbers for the Zoom service. None of that was fabricated. An analyst looking at just the links would have found nothing wrong.

What the Attacker Actually Built

The construction here is more deliberate than a typical phishing template. This wasn't a bulk credential-harvest campaign sprayed at random inboxes.

Someone researched the target organization, identified a real employee with a recognizable role in channel partnerships, and crafted a scenario that would be entirely plausible to that person's colleagues. LinkedIn, company websites, and partner program pages give an attacker enough material to reconstruct a believable B2B interaction without ever attending a conference.

The email reached three specific recipients, all of whom would have had reason to be involved in an ANZ distribution conversation. That targeting reflects prior reconnaissance or a plausible inference about who handles partner relationships. Either way, it was not random.

The sending domain, registered in Australia with a legitimate business registrant and active name servers, passed every automated reputation check. It had no prior abuse history. Its authentication infrastructure was properly configured, which is why SPF and DKIM returned pass results. The domain was not freshly registered the same day, which removes one of the most reliable signals used to catch other calendar-based attacks.

MITRE ATT&CK maps the core technique to Masquerading (T1036) for the identity substitution in the calendar organizer field, and Spearphishing Attachment (T1566.001) for the .ics delivery vehicle. The social engineering layer aligns with Phishing for Information (T1598), targeting the trust relationship between the recipients and the impersonated employee.

See Your Risk: Calculate how many threats your current security stack is missing

Where the Authentication Story Ends

The gap this attack exploits is architectural. Email authentication standards, SPF, DKIM, and DMARC, are designed to validate the domain in the envelope sender and the From header. They are not designed to validate calendar metadata. The ORGANIZER field in an ICS file is a freeform string. You can put anyone's name and email address there, and no authentication mechanism will catch the discrepancy.

This means that a message can arrive with a perfect authentication record and still be presenting a completely false identity in the part of the message the recipient actually reads.

The Microsoft Digital Defense Report 2024 notes that attackers are increasingly abusing trusted infrastructure precisely because authentication controls give those messages a clean pass (Microsoft Digital Defense Report 2024). The calendar invite is not flagged by URL scanning. The .ics payload contains no malicious code. The Zoom link, the Calendly link, the ironscales.com references in the signature: every individual element checks out.

The tell was not in any single artifact. It was in the relationship between the envelope sender and the organizer identity. A sending domain that had no established relationship with the target organization, contacting recipients through a channel, specifically a calendar invite, where impersonating an internal contact is trivially easy and largely invisible to standard controls.

Themis flagged this as a first-time sender with high sender risk, and labeled it as suspected malicious content targeting a VIP recipient. Three mailboxes were quarantined within minutes of delivery. The confidence score was 66%, reflecting the genuinely ambiguous technical picture: nothing about the authentication was wrong. The wrongness was in the context.

Indicators of Compromise

What Calendar-Layer Attacks Require You to Rethink

Standard email security evaluates messages at the header and body level: SPF, DKIM, URL reputation, attachment sandboxing. Calendar invites pass most of that evaluation because the format is trusted and the delivery mechanism is legitimate.

The attack surface in calendar-based impersonation is the metadata layer. ORGANIZER, SUMMARY, and DESCRIPTION fields are populated by the sender and displayed to the recipient as if they were part of the message envelope. They are not. They are content, and they can contain anything.

Detection requires cross-referencing the calendar ORGANIZER against the authenticated envelope sender. If those two identities don't share a domain, that mismatch is worth evaluating. First-time sender flags matter even more for calendar invites than for regular email, because a calendar invite carries an implicit action: the recipient accepts the meeting and it goes onto their calendar.

Verizon's 2024 DBIR notes that social engineering attacks succeed most reliably when they align with something the target already expects (Verizon DBIR 2024). A follow-up invite from an ANZ distributor after a partner webinar is not surprising. That's the window this attack was built to fit through.

Authentication tells you the envelope is legitimate. It says nothing about whether the identity in the calendar is the same person.