A Zoom Calendar URL Where the Sender Should Be

The subject line was the first thing that made no sense. Instead of a topic, it carried a bare forty-character hexadecimal string, then a date, then REF. ID:7917166692. No sentence, no product name, nothing a person would ever type. It read like a database key that had escaped into the open. It reached exactly one mailbox, belonging to a business officer in the campus facilities group at a public university, and the subject line was not the strangest thing about it.

That distinction belongs to the sender.

A meeting invite where the address should have been

Email identity lives in two places: the display name a client shows you, and the address a parser reads. This message abused both at once, in a single field. The display name read IT_Service|Department|infodonotreply, three fragments run together with pipe characters, a shape no real helpdesk mailbox produces. The address that followed did not stop there. It continued with another pipe and then an entire Zoom meeting URL, host and path and query string intact: us06web[.]zoom[.]us/meeting/tZEqcO6opzIqGtbiruXsBFttr6l7a9gdi3Ks/ics?icsToken=DJxpcxhWcUPBpRuChQAALAAAAPCh3DN2Uycb..., complete with a full calendar subscription token and a meetingMasterEventId value, before finally terminating in a real mailbox at @orionart[.]com[.]au.

That URL is the link Zoom hands you when you add a meeting to a calendar, pasted whole into the sender field. Whether that was deliberate obfuscation or a kit concatenating the wrong template variable, the effect is the same. Most clients render only the leading fragment and truncate the rest, so the recipient sees something resembling an IT alias, while a parser expecting a well-formed address gets a string it was never designed to score. This is masquerading in the sense of MITRE ATT&CK T1036/005, achieved not by forging a convincing identity but by submitting one too malformed to evaluate.

The authentication got better as the message traveled

The first SMTP hop came from 5[.]161[.]235[.]1, whose reverse DNS resolved to static[.]1[.]235[.]161[.]5[.]clients[.]your-server[.]de, a rented virtual server at a German hosting provider. That hop failed SPF outright, carried no DKIM signature, and had no DMARC alignment to speak of. On its own it is a clean rejection.

Then the message passed through the genuine Microsoft 365 outbound infrastructure of orionart[.]com[.]au, a real Australian business with a real tenant and a verified DKIM selector of its own. The second hop tells a completely different story: SPF pass, DKIM pass signed by that company's tenant, ARC pass, DMARC best-guess pass, composite authentication pass with reason 109. An untrusted origin had been laundered into a legitimate one, which is the signature of an abused or compromised mailbox at a real company rather than a domain spoof.

Read at the mailbox, this message is authenticated. Read at the origin, it never was. DMARC as specified in RFC 7489 reports on alignment for the domain it can see, and a best-guess result is an inference, not a verdict. The 2024 Verizon Data Breach Investigations Report put stolen credentials in 38% of breaches, the single most common initial action, and attacks like this one are why: the attacker never had to defeat authentication, only to borrow somebody who already passed it.

A cancellation nobody had requested

The body impersonated Microsoft, badly and effectively at the same time. The header read OFFlCE-365 in oversized red type, with a lowercase L standing in for the capital I, the sort of substitution that survives a glance and defeats a literal string match. The copy announced that a service deactivation request had been approved, and invited the reader to confirm access below to cancel the deactivation if they had not requested it.

That is reverse urgency, and it works better than the usual kind. A password-expiry notice asks you to do something. This one says a destructive action is already approved and in motion, then offers one button to stop it, converting caution into a click. CISA's phishing guidance treats that moment as the pivot point of the attack cycle, and it is why credential harvesting remains the cheapest path into a tenant, matching the NIST definition of phishing almost to the letter.

Two vendors rewrote the link and neither stopped it

The Confirm Access button is where this case stops being ordinary. Unwrapped from the outside in, it resolved first to nam11[.]safelinks[.]protection[.]outlook[.]com, Microsoft's own URL-protection service. Inside that wrapper sat a secure-web[.]cisco[.]com address, Cisco's Secure Email rewrite service. Inside that sat the actual destination: hxxps://maestranzanaval[.]cl/.well-known, a path on the website of a Chilean shipyard company with no relationship to anyone involved.

Two independent email security products had each taken custody of the same malicious link, rewritten it into their own namespace, scanned it, and passed it along. Both verdicts came back clean. Rewriting a URL is a custody mechanism, not a judgment, and the outer wrapper made the visible destination look like a Microsoft hostname while doing nothing about what waited at the end. That is delivery by spearphishing link and, on the click, user execution of a malicious link, arriving pre-blessed by two scanners. It is also the clearest argument there is for layering behavioral detection alongside an existing gateway rather than treating its verdict as final.

See Your Risk: Calculate how many threats your SEG is missing

The landing path is its own tell. The /.well-known directory exists for machine-readable service-discovery files, not human-facing pages. Content sitting there suggests an attacker with write access to a legitimate site who picked the one folder its owners never look at, leaving the host's real pages and reputation undisturbed.

The kit forgot to clear its own history

Below the fake notice, the message quoted an entire unrelated business thread from the previous autumn, in which employees of an agricultural equipment manufacturer and a life-sciences supplier discussed an order for an air pressure sensor. It had nothing to do with the university, the deactivation pretext, or Zoom. The signature block was intact, which is why a handful of legitimate corporate social-media links showed up in the extracted link list looking briefly like infrastructure. They were residue, not indicators. Someone built this lure on a real message harvested long before and never cleaned the template, which is diagnostic in itself: a kit reused across campaigns, recipient list swapped, pretext replaced.

What actually caught it

By the time the message arrived there was no failed gate to point at. Authentication was clean, the link had been cleared twice, the payload was a button. Detection came from the pattern instead of the verdict, and IRONSCALES Adaptive AI resolved the message as phishing automatically, with no analyst action required and none taken. Outlook also rendered an external-sender banner noting the mail came from outside the university, a warning that helps precisely because it does not depend on any scanner agreeing.

Every signal that mattered was behavioral: a subject line with no human content, a sender field containing a URL, a brand claim with none of the brand's infrastructure behind it, a twice-wrapped link to a service-discovery path on a foreign domain. Individually each is arguable. Together they are not.

The lesson is narrow and worth keeping. Authenticated is not legitimate, and scanned is not safe. A relay can turn a failure into a pass, and a URL rewriter can hand a hostile link a trusted-looking hostname while its scanner shrugs. When the only thing wrong with a message is everything about how it behaves, something has to be reading behavior.

Indicators of Compromise

MITRE ATT&CK Mapping

• T1566/002, Phishing: Spearphishing Link. The Confirm Access button was the entire payload.
• T1204/001, User Execution: Malicious Link. The click through two rewrite layers triggered the harvest attempt.
• T1036/005, Masquerading: Match Legitimate Name or Location. A fake helpdesk identity, a misspelled Microsoft logo, and a legitimate tenant borrowed for delivery.