The Fake Virtru OTP That Outed Its Own Mass-Mailer

An encrypted-message notification arrived in a mailbox at a US mortgage banking company. It was branded, top to bottom, as Virtru, the secure-email and encryption platform. It carried a live one-time code and a single button that read Verify me. To anyone who regularly opens protected messages, this is muscle memory: click, confirm, read the contents.

One detail broke the spell. The user identity baked into that Verify me link did not belong to the person who received the email. It belonged to an employee at an unrelated title company several states away.

That is not a rounding error. It is a fingerprint. A legitimate encrypted-message notification mints a link tied to the recipient it is sent to. When the same link shows up in someone else's inbox carrying someone else's identity, you are not looking at a bespoke lure. You are looking at a reused mass-mailer template that blasted the same message to a list and never bothered to rewrite the token.

A Domain That Signed For Itself

The message came from jkadsstudio[.]com, a domain registered roughly three months before the campaign through a budget registrar with an India-based registrant. It was pushed out over Amazon Simple Email Service, relayed through a Votiro content-disarm sanitization hop, and delivered into the target's Microsoft 365 tenant.

Here is where the authentication story gets uncomfortable. DomainKeys Identified Mail (DKIM) passed cleanly, with valid signatures for both jkadsstudio[.]com and amazonses.com. DMARC passed as well, aligned to the header From, with a policy action of none. Microsoft's composite authentication logged compauth=pass with reason=100. The only mark against it was SPF, which returned None because the SES sending address was not covered by the domain's published SPF record.

Read that again. Three of the four signals a defender leans on came back green, and they came back green honestly. The attacker was not spoofing anyone. He sent from a domain he owned and signed it correctly, so the mail genuinely came from where it claimed. DKIM confirms a message was not tampered with in transit. DMARC confirms the sending domain aligns with itself. Neither one asks the question that actually matters here, which is whether the sender should be trusted at all. Authentication passing is not evidence of safety when the sender controls the domain being authenticated.

Following the Verify Me Button

The Verify me call to action did not point straight anywhere. It was wrapped in Microsoft Safe Links, then routed through links.notification.intuit[.]com, a real Intuit notification-tracking domain borrowed as a clean-looking redirect hop, before finally resolving to a genuine api.virtru[.]com/accounts/email-activation endpoint.

That is a well-built chain. The Safe Links wrapper looks like protection working. The Intuit hop lends a recognizable brand to the redirect. The final Virtru endpoint is the real thing, which means a URL reputation engine inspecting the destination finds a legitimate SaaS domain and waves it through.

The userId parameter on that activation URL is what gives the game away. It is an email address, and it is not the recipient's. It resolves to a mailbox at an unrelated title company, a different victim entirely. A second call to action in the body pointed off to yet another unrelated domain, unionsmgt[.]us, with no relationship to Virtru, the bank, or the title company. The template was stitched together from artifacts of prior sends and shipped without cleanup.

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

Mapping to MITRE ATT&CK

The tradecraft maps cleanly onto the MITRE ATT&CK framework:

• T1566 Phishing and T1566.002 Spearphishing Link cover the core delivery: a socially engineered notification whose payload is a link, laundered through wrappers and a trusted-brand redirect.
• T1204.001 User Execution: Malicious Link covers the intended outcome, a recipient clicking Verify me and walking into an activation flow that was never meant for them.

Indicators of Compromise

Detection and What to Watch For

Reputation and signature checks were always going to lose this one. The sending domain authenticated correctly, the redirect chain touched two well-known brands, and the final destination was a real SaaS endpoint. There is no bad signature to catch and no blocklisted host to trip on.

Detection has to move to behavior and relationships. The signals that matter are a brand-new sending domain wearing an established platform's clothing, an OTP notification whose activation identity does not match the mailbox it landed in, and a redirect chain that leans on a trusted third-party tracking domain to reach its endpoint. Those are the things a human analyst would notice and a static gateway will not.

That is the layer Themis, the Adaptive AI analyst on the IRONSCALES platform, is built to read. It weighs the relationship between the claimed brand, the actual sending domain, and the identity carried through the link, flagging the impersonation even when every server-level check comes back clean. Across 35,000+ security professionals in 17,000+ organizations, the pattern is consistent: the messages that slip past authentication are the ones that were authenticated correctly by an attacker who owns his own domain.

The scale problem is real. The 2024 Verizon Data Breach Investigations Report found phishing present in 15 percent of breaches and clocked the median time to click a phishing link at 21 seconds, with data submitted just 28 seconds after that. The Microsoft Digital Defense Report 2024 documents the same drift toward abusing trusted services rather than breaking them, and the FBI's 2023 Internet Crime Report ranks business and identity impersonation among the costliest fraud categories reported that year.

The Takeaway

A green authentication result answers one narrow question: did this mail come from the domain it claims. It does not answer whether that domain deserves your trust, and a barely-registered domain that signs its own Virtru knockoff will pass every alignment check you throw at it. The forensic gift in this case, an activation link stamped with the wrong victim's identity, will not always be there. Build detection that reads intent and relationships, not just headers, and treat credential-harvesting notifications as claims to verify rather than facts to act on. CISA's guidance on recognizing and stopping phishing early is a solid reference for building that reflex across a team: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one