A Teams Invite With Two Links That Both Lied

The most convincing detail in this Microsoft Teams meeting invite was not the meeting ID or the six-digit passcode. It was the join link. There were two of them, and both displayed a genuine teams.microsoft.com/meet/... address in the visible text. Neither one actually pointed there.

A CFO at a healthcare and human-services organization received a calendar invitation for a "Management Progress Meeting." It carried everything a real Teams invite carries: a meeting ID, a passcode, a "Need help?" line, a "Meeting options" link, and a valid .ics attachment. The sender identified itself as "Office Calendar Service." The email passed SPF, DKIM, and DMARC cleanly. On every surface a person or a filter typically checks, it looked legitimate.

Here is what made it work.

Two join links, one real Teams URL, zero real destinations

The invite contained two link elements. Both rendered display text reading a legitimate Microsoft Teams join URL. Both resolved, on click, to superiorsynthetics4u[.]com, a third-party domain with no relationship to Microsoft, Teams, or the sending platform.

This is the display-text-versus-href mismatch, and it is deceptively simple. The blue, underlined text a recipient reads says teams.microsoft.com. The href attribute underneath sends the browser somewhere else. A human scanning the visible link sees a real Microsoft address and clicks with confidence. The label is the disguise. MITRE tracks this technique as Masquerading (T1036.005), and NIST's own definition of phishing turns on exactly this: getting a target to reveal information or click by posing as a trustworthy source.

The attacker did not stop at one copy. The first link pointed directly at the mismatched domain. The second routed the same destination through dcvvq7hs.r.us-east-1[.]awstrack[.]me, Amazon's own click-tracking wrapper. Two roads, same trap, delivered through the machinery of legitimate email marketing.

Why every authentication check waved it through

The sender address was donotreply[@]getthereferral[.]com, a domain registered back in 2014. This is not attacker infrastructure. It is an established SaaS and calendar platform, apparently abused as a sending relay. Delivery came through Amazon SES (a48-109[.]smtp-out[.]amazonses[.]com, IP 54[.]240[.]48[.]109), and because the mail genuinely originated from that platform's authorized infrastructure, SPF, DKIM, and DMARC all passed.

That is the trap in authentication-only thinking. Those protocols answer one question: did this message come from where it claims to come from? Here the answer was honestly yes. The platform really sent it. What SPF, DKIM, and DMARC cannot evaluate is whether the content inside a legitimately sent message is hostile. The 2024 Verizon Data Breach Investigations Report found phishing present in 15% of breaches and the human element in 68%, with a median time to click a phishing link of just 21 seconds. Against a 21-second window, a link that reads as a genuine Microsoft URL does not need to fool anyone for long.

Piggybacking Amazon's own click-tracker

The second, wrapped link is the part worth studying. awstrack.me is Amazon SES's legitimate open- and click-tracking service. Marketers use it every day. By formatting the malicious redirect to match Amazon's real tracking-link structure, the attacker gained two things: a URL that looks like ordinary email-platform telemetry, and a redirection hop that many filters treat as trustworthy because the wrapper domain belongs to Amazon. MITRE catalogs this as Web Service abuse (T1102.002), bending a widely trusted service to relay attacker traffic. It is the same instinct behind Spearphishing Link (T1566.002): reach the target through a channel they already trust.

The .ics attachment, meanwhile, was a red herring. We verified it. No embedded URLs, no scripts, no macros. A structurally valid calendar file whose only job was to make the invite feel real.

The destination itself gave up almost nothing. When scanned, superiorsynthetics4u[.]com returned an empty response, no content served. We are not going to assert what the page was built to do, because at scan time it did nothing. What the domain does show is a weak-hygiene profile: registered in 2015, no SPF, no DMARC, no MX records, and no resolvable reverse DNS. That is not how a real meeting host's infrastructure looks. CISA's guidance on stopping the phishing attack cycle puts link inspection at the center of the earliest phase for precisely this reason.

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

Where the mismatch actually surfaced

None of the usual controls were positioned to catch this. Authentication passed. The visible link text read as Microsoft. The attachment was clean. Reputation on the sending platform and on Amazon SES was good. The Microsoft Digital Defense Report 2024 makes the same point at scale: attackers increasingly ride legitimate infrastructure precisely because reputation-based defenses give it a pass.

The only reliable signal was href resolution, comparing what each link says against where it actually goes. That is the layer our Adaptive AI, Themis, evaluates. Themis reads the message the way an attacker built it, not the way it renders. It flagged the divergence between the displayed Teams URL and the true destination, the second link's redirect through a tracking wrapper to that same low-reputation domain, and the behavioral mismatch of a calendar service delivering a CFO an off-platform "join" link. IRONSCALES platform data frames the gap plainly: secure email gateways miss an average of 67.5 phishing emails per 100 mailboxes each month, and mismatched-href lures like this one are exactly the category that slips through, because a gateway checks the sender and the visible surface, not the underlying link.

The stakes were not abstract. A finance authority at a healthcare and human-services provider is exactly the target business email compromise and credential operators prize. And because the lure impersonated a collaboration platform, it lands in the same blind spot that dedicated collaboration tool protection is built to close.

Indicators of Compromise

MITRE ATT&CK: T1566.002 (Spearphishing Link), T1036.005 (Masquerading via display-text and href mismatch), T1102.002 (Web Service, a legitimate click-tracker abused for both a benign-looking and a malicious link).

Resolve the href, not the label

The lesson here is narrow and it is durable. Do not let a link's visible text stand in for its destination. Configure your controls to resolve every href and follow every redirect to its final landing point, then compare that against what the link claims to be. A wrapper domain you trust, Amazon's included, is a hop to inspect, not a verdict to accept. When the displayed address and the true destination disagree, the displayed one is the disguise.