Every link in this email resolved to a domain your security team would recognize. Stripe. SendGrid. A legitimate AI persona platform. The URL scanners checked each hop, found known infrastructure at every stop, and returned the same verdict: clean.
They were wrong.
A phishing campaign targeting a mid-size forensic engineering firm wrapped its payload inside a helpdesk ticket notification, routed every clickable link through Stripe's own email click-tracking subdomain, and terminated the redirect chain at an AI agent vendor platform that has nothing to do with the victim organization. SPF failed. DKIM failed (body hash mismatch). DMARC failed with a quarantine action. But the ticket-wrapper format buried every authentication red flag beneath the kind of internal warning banners that employees scroll past dozens of times a day.
The email presented itself as a notification from Link by Stripe, informing recipients of updates to their Terms of Service and Privacy Policy. The formatting was professional. The branding was pixel-perfect. The footer included Stripe's corporate address in South San Francisco. The body stated that no action was required, which is exactly the kind of low-urgency language that gets recipients to lower their guard before clicking the embedded links.
But the email didn't come from Stripe.
It arrived from hd@envistaforensics[.]com, the victim organization's own domain, with a Return-Path pointing to a SendGrid bounce address at em6707.envistaforensics[.]com. The message traversed SendGrid's outbound infrastructure (167[.]89[.]17[.]225) before hitting a Barracuda ESS gateway (209[.]222[.]82[.]7) and finally landing in Microsoft Exchange Online. At each relay hop, the authentication story fell apart. The receiving infrastructure recorded SPF fail (the Barracuda IP was not authorized for the sender domain), DKIM fail (the body hash did not verify, meaning the message content was altered after signing), and DMARC fail with action=quarantine.
Three simultaneous authentication failures. And the email still landed.
The real sophistication was not in the email body. It was in the links.
Every clickable URL in the email used one of two redirect patterns. The first routed through 58.email.stripe[.]com, Stripe's click-tracking subdomain for transactional email. The second used u4902006.ct.sendgrid[.]net, SendGrid's standard click-tracker. Both are legitimate infrastructure used by millions of organizations for routine email analytics. Both carry strong domain reputation scores. And both function as open redirects that forward the user to whatever destination the sender specifies.
URL scanners evaluate the domain they see. When that domain is Stripe or SendGrid, the verdict comes back clean. According to Microsoft's Digital Defense Report 2024, attackers increasingly exploit trusted intermediary services to evade domain-reputation-based filtering, a technique that renders static URL analysis insufficient against layered redirect chains.
The scanners never followed the chain to its endpoint. That endpoint was envistaforensics.virtualpeople[.]ai/agent-ui-v2/inbox/INC-6204, a page hosted on VirtualPeople, a legitimate AI persona and agent platform. The subdomain was customized with the victim organization's name. The path referenced the same ticket number (INC-6204) used in the email subject line. The attacker designed every element of the redirect to look like a routine SaaS interaction between a company and a vendor it already uses.
All 20+ links in this email were scanned by automated tools. Every single one returned a clean verdict.
See Your Risk: Calculate how many threats your SEG is missing
The email did not arrive as a raw phishing message. It was packaged inside a helpdesk ticket notification with the subject line "INC-6204 - [Phish Alert] Updates to Link's Terms of Service and Privacy Policy." The body opened with "New Ticket Assigned to Queue," listed a queue name, a submitter, and a description field. This ticket-wrapper format (mapped to MITRE ATT&CK T1036.005, Masquerading: Match Legitimate Name or Location) served two purposes.
First, it gave the email a plausible reason to originate from inside the organization. Helpdesk systems routinely send notifications from internal addresses, so a message from hd@envistaforensics[.]com looked normal even though authentication checks said otherwise.
Second, it pre-loaded the email with warning banners. The body included both "External sender" and "Warning: Unusual sender" labels. These banners are supposed to protect recipients. In practice, employees at organizations using multiple SaaS platforms see these banners constantly on legitimate traffic. The FBI IC3 2024 report documented $2.9 billion in BEC losses, many involving attacks that exploited the gap between security warnings and human attention. The banners become noise. The attacker counted on that.
The IRONSCALES community intelligence network identified this campaign with 90% confidence. What triggered the flag was not any single signal but the correlation of behaviors: triple authentication failure combined with redirect chains terminating outside the organization's known vendor ecosystem, delivered to six recipients simultaneously. Static scanners that evaluated each link individually saw clean domains. Behavioral AI analysis that evaluated the full context (who sent it, how it authenticated, where the links actually went, and how many people received it at once) saw a coordinated campaign.
| Type | Indicator | Context |
|---|---|---|
| Sender | hd@envistaforensics[.]com | Spoofed internal helpdesk address |
| Return-Path | bounces+4902006-2086-cory.bergstrom=envistaforensics[.]com@em6707.envistaforensics[.]com | SendGrid bounce address |
| Relay IP | 167[.]89[.]17[.]225 | SendGrid outbound (xtrwkkzk.outbound-mail.sendgrid[.]net) |
| Relay IP | 209[.]222[.]82[.]7 | Barracuda ESS outbound (outbound-ip137a.ess.barracuda[.]com) |
| Redirect Domain | 58.email.stripe[.]com | Stripe click-tracking subdomain used as redirect |
| Redirect Domain | u4902006.ct.sendgrid[.]net | SendGrid click-tracker used as redirect |
| Landing URL | hxxps://envistaforensics[.]virtualpeople[.]ai/agent-ui-v2/inbox/INC-6204 | Final redirect destination, AI persona platform |
| Auth Result | SPF=fail, DKIM=fail (body hash), DMARC=fail | Triple authentication failure for envistaforensics[.]com |
This attack did not require a zero-day exploit, a compromised account, or a convincing visual clone of a login page. It required one insight: URL scanners trust brands, not destinations.
The Verizon 2024 DBIR found that social engineering remains the primary initial access vector in confirmed breaches. What is changing is the infrastructure layer. Attackers are selecting their redirect hops for brand credibility, not just technical function. Stripe and SendGrid are not accidental choices. They are calculated ones. A redirect through payment infrastructure followed by an AI vendor platform creates a chain where every individual component looks like normal SaaS traffic.
The defensive takeaway is straightforward. Authentication results need to be evaluated as a correlated set, not individually. A message that fails SPF, DKIM, and DMARC simultaneously and contains redirect chains terminating outside the sender's known ecosystem is not a marginal case. It is a high-confidence indicator. Organizations using SEG augmentation or layered behavioral analysis should ensure their policies enforce DMARC failures rather than silently quarantining them, and that link analysis follows redirects to their final destination rather than stopping at the first trusted hop.
The scanners saw Stripe. They stopped there. The attack continued.