Three Brands, One Lure: A Chase 'Secure Message via Virtru' That Actually Came From LinkedIn

A "secure message" notification is one of the safest-looking emails a bank can send. It is also one of the easiest to fake, because the entire template is a wrapper: a logo, a reassuring paragraph, and a single button that says click here to read your message. There is nothing to inspect except the trust you already have in the brand.

The message that reached this organization's mailboxes in June leaned on exactly that. It carried Chase branding top to bottom, a header banner in Chase blue, the Chase logo, a "© 2026 JPMorgan Chase & Co." footer, and it announced a new secure message via Virtru. Clean, corporate, and completely inconsistent the moment you look past the surface. See how IRONSCALES catches what your gateway misses.

Three Identities That Never Agree

Strip the branding away and the email describes three different senders at once:

• The visible brand is Chase. Logo, color, footer, and the "Chase won't ask for confidential information in an email" boilerplate all impersonate JPMorgan Chase.
• The claimed provider is Virtru. The headline reads "Read your new secure message via Virtru," borrowing the name of a legitimate email-encryption vendor to explain why the recipient has to click through instead of just reading the message inline.
• The actual sender is LinkedIn. The From header on the message resolved to messages-noreply@linkedin[.]com, LinkedIn's own notification address, which has nothing to do with either Chase or Virtru.

Chase does not deliver statements through Virtru, Virtru is not LinkedIn, and LinkedIn does not send banking notifications. Any one of those pairings is odd; all three in one message is the tell. This is deliberate. A recipient who banks with Chase, or who has seen a Virtru secure message before, or who simply recognizes LinkedIn as a familiar sender, has a reason to trust the email, and the attacker only needs one of those threads to catch. It is the same multi-brand layering that shows up whenever attackers want to raise the odds that something in the message feels legitimate.

The Buttons Borrow a Security Vendor's Reputation

The call-to-action was the interesting part. The message contained several "Secure Message" and "chase.com/CustomerService" buttons, and every one of them pointed not at Chase but at a Mimecast URL-protection domain:

hxxps://url.us.m.mimecastprotect[.]com/s/Wa6jCyPDKLiYxPZocMh9cxhou9?domain=chase.com

url.us.m.mimecastprotect.com is real. It belongs to Mimecast, and it is the domain their email-security gateway uses to rewrite customer links so they can be re-scanned at click time. That is precisely why it is useful to an attacker. A wrapped link inherits the reputation of a recognized security vendor: automated URL-scoring engines see a trusted rewrite domain, and a cautious user who hovers the link sees mimecastprotect.com rather than wherever they are actually being sent. The redirect ultimately resolves toward chase.com-flavored content, keeping the illusion intact while the reputation of the wrapper does the heavy lifting.

Link wrapping by a gateway is normal, benign infrastructure. Using someone else's wrapper as a trust-laundering layer is the recurring redirect-laundering pattern we see across these teardowns: the abuse is not a fourth impersonated brand, it is a way to make the first three look verified.

The Template Was Stale Out of the Box

Convincing branding, sloppy execution. The body is full of the small errors that mark reused, mass-produced content:

• The notice was already expired on arrival. The email stated, "The secure message will expire on 06/16/2026." The incident was raised on June 25. A real time-sensitive notification does not ship pre-expired; a template that has been recycled across a campaign does.
• The grammar breaks. The lead line reads, "Read your here Secure Message because it contains specific information about your current transactions/requests." That is not copy a bank ships.
• The pretext is generic. The "about" line was a bare ACH_Incoming_Payments label, with no recipient name, no account fragment, no amount. The related messages in this campaign used interchangeable finance hooks like "Failed Transactions" and payment notifications, generic enough to drop on any accounts-payable or finance mailbox.

None of these individually proves phishing. Together they describe a canned kit sprayed at finance staff, dressed up in enough Chase branding to clear a glance.

How Themis Pulled It Apart

IRONSCALES Themis Adaptive AI classified the message as phishing at 90% confidence and it was automatically resolved and remediated across the affected mailboxes.

The detection did not hinge on an authentication verdict, and that is the point. The signals that mattered were relational and reputational:

This is why AI-powered email security has to reason about identity and intent, not just parse headers. The Verizon 2025 DBIR still puts phishing among the top initial-access vectors, with credential harvesting as the dominant objective, and the FBI IC3 2024 Internet Crime Report tallied $2.77 billion in business email compromise losses, with finance functions squarely in the blast radius. A "secure message from your bank" is a cheap, high-yield way in.

What Defenders Should Do Now

Teach the three-way check. The durable lesson here is not a specific indicator, it is a habit: the brand you see, the address it was sent from, and where the link actually goes should all describe the same organization. When they don't, stop. That check would have flagged this email in seconds without any tooling.

Don't treat a recognized rewrite domain as safe. mimecastprotect.com, safelinks.protection.outlook.com, and their peers are gateway wrappers, not endorsements. Unwrap the link and judge the final destination.

Verify secure messages out of band. If a message claims your bank is holding something for you, log in directly at the institution's known site or call the number on the back of your card. Never navigate through the email's own button.

Weight identity mismatch over authentication. Pass or fail on DKIM and DMARC is one input, not a verdict. An email can be technically authenticated and still be a lie about who it is from; here the branding, sender, and link host disagreed regardless of the header result.

---

MITRE ATT&CK Mapping

Indicators of Compromise