A Zix Secure Message Alert That Opened a ClickUp Form

The email announced itself as a secure message. A banner across the top read New Zix secure email message, the line under it named a company the recipient already did business with, the subject referenced an approved pay application invoice, and a single button sat in the middle of the body: Open Message. A footer note added pressure, warning that the secure message would expire, with the deadline set a few days out.

The recipient worked at a national home care services provider. The sender was a named contact at a third-party senior living services vendor, and the two organizations had traded mail before. So a secure-message notification carrying an approved pay application reference did not read as unusual. Vendors send payment documents, and they send them through encryption portals.

The one detail that did not hold up was the destination. The Open Message button did not point at Zix, or at any secure-message platform. It pointed at a form hosted on ClickUp.

Vendor Account Compromise, Not Domain Impersonation

Start with what this attack did not do, because the absence of the usual tells is the whole story. There was no lookalike domain, no unicode homoglyph, no hyphenated near-miss, no throwaway registration standing in for a trusted brand. The message came from the vendor's real domain, left through that organization's own outbound Mimecast gateway, and carried a DKIM signature generated with that organization's own key. SPF passed. DKIM passed and aligned. DMARC passed under a published quarantine policy.

Every one of those checks answered truthfully. That is the point: authentication confirms a message traveled from infrastructure the domain owner authorizes, not that the human who owns the mailbox is the one pressing send. When an attacker is operating inside a legitimate account, vendor email compromise turns the entire authentication stack into a credibility engine working for the wrong side.

The message structure confirmed compromise rather than forgery. Both the From and To headers carried the same vendor mailbox, a self-addressed send with onward delivery to the recipient, the signature of somebody working through a mailbox they control rather than spoofing a header they do not. Two mailboxes at the recipient organization received it.

A Secure-Message Brand the Sender Never Used

The lure's cleverness was the brand it borrowed. Zix is a real encrypted-email service, and a genuine Zix notification behaves exactly the way this message imitated: a placeholder body, no readable content, and a retrieval button that sends you elsewhere to authenticate. The pretext explains away its own strangeness: a vague subject line is expected, an extra sign-in is expected, and the expiry warning that manufactures urgency is not even a lie in the original, since real secure messages do lapse.

The vendor, however, does not use Zix. The overlay was a costume pulled over a mailbox that already had all the trust it needed, and it existed for one reason: to make an unexplained credential prompt feel procedural.

The Credential Form Lived on a Project Management Platform

Clicking Open Message resolved to forms[.]clickup[.]com, a form builder on ClickUp's own production infrastructure. The credential collection happened on a page the attacker built with a no-code tool, served over a valid certificate from a domain carrying years of legitimate business traffic.

Both links in the message were scanned and both came back Clean. The secondary footer link, framed as a place to review support documentation, pointed at Microsoft's genuine support site and did nothing malicious at all, existing purely to make the footer look like a real product notification.

This is what breaks reputation-first filtering. A URL scanner asks whether the host is known bad. forms[.]clickup[.]com is emphatically known good, and blocking it wholesale would break a tool legitimate teams use every day. The attacker did not evade the reputation check. They satisfied it. According to the 2024 Verizon Data Breach Investigations Report, stolen credentials were involved in 38 percent of breaches and phishing appeared in 15 percent, and campaigns that hand scanners nothing but trusted hosts are why those numbers stay stubborn.

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

What Themis Weighed Instead

The platform's own sender heuristics had nothing to work with. The first-time-sender flag did not fire, because the vendor had legitimate sending history with this organization. The impersonation flag did not fire, because nobody was impersonating anybody at the header level. Strip out authentication, sender history, and link reputation, and a conventional gateway is out of arguments.

What remained was a contradiction. A notification wearing one platform's secure-delivery branding, whose only call to action resolved to an unrelated platform's form builder, sent from an account that had never used the claimed service, with an expiry clock attached to an invoice approval. The Adaptive AI behind Themis scored that combination as credential theft at 90 percent confidence and the incident resolved automatically as phishing. No indicator in the message was individually suspicious. The relationship between them was.

MITRE ATT&CK Mapping

• T1566.002 Phishing: Spearphishing Link: the entire payload was one link, styled as a secure-message retrieval button.
• T1078 Valid Accounts: delivery relied on a genuinely compromised vendor mailbox, which is what produced the clean authentication result.

Indicators of Compromise

What This Attack Should Change

Three shifts follow from a case with no bad domain and no bad link.

First, validate the claim against the destination. If a message says it is a secure-message notification, the retrieval link should belong to that platform, and a mismatch between claimed brand and resolved host deserves to be treated as hostile on its own. The CISA phishing guidance makes the broader version of this point: technical controls have to be paired with detection that reads context, because the definition of phishing in the NIST glossary turns on deception, not on infrastructure quality.

Second, stop treating trusted SaaS hosts as inherently safe link destinations. Form builders, document platforms, and no-code app hosts are now standard credential-page real estate precisely because their reputation is unimpeachable. Credential-harvesting protection has to reason about what a page asks for and how the message framed it, not just where it is hosted.

Third, plan for compromised partners, not only for impostors. A vendor with real history and clean authentication is the highest-trust delivery channel an attacker can obtain, and every control keyed to spotting outsiders will wave it straight through. Payment-instruction and document-retrieval requests from established vendors need verification through a channel that does not run over email.