A few weeks ago, a message landed in a customer’s inbox that, by all traditional metrics, was impeccable. The sender was a household Fortune 50 brand. SPF passed. DKIM was signed by the legitimate provider. Reputation scores were green across every threat feed we cross-checked. Naturally, the user's existing email security stack waved it through without a single flag.

It was a phish.

The trust signals weren't forged, they were objectively true. The malicious content was being carried by (and in some cases, authored by) infrastructure that no enterprise can block without shutting down global business operations.

That message isn't an anomaly; we see variations of it every day. What is unusual is the industry’s imprecise language regarding the attack class behind it. "Trusted Infrastructure" actually describes two structurally distinct attack models that happen to share the same trust boundary and name. Because they are fundamentally different, they require different defensive postures, yet most security stacks are only built to stop one of them.

The half the industry has been chasing for years

The familiar version of trusted infrastructure abuse is centered on delivery. A real Google Drive share. A real OneDrive link. A real DocuSign envelope. In these cases, the email body is surgically clean, the sender is the legitimate platform, and the malicious content lives exactly one click away—inside the shared file, on the page the link resolves to, or behind a formal signature request.

This pattern is not new. The security industry has been working to solve it for the better part of a decade. Modern stacks are designed to unpack the share, follow the link, and detonate the file. However this problem is not solved.  Attackers routinely defeat it with authentication walls, geofencing, time-bombed links that go inert before automation can reach them, and bot-detection layers that serve a clean page to anything that looks like a sandbox. Traditional stacks still get bypassed here, regularly. 

While the discipline of following a trail to a payload is well-established, these attacks still consistently bypass traditional solutions. We can call this the "reachable" half. It isn't easy to stop, but at least the signal lives in a space where the security industry knows how to hunt.

If that is the half everyone has been working on, the question worth asking is: What does the other half look like, and why has it not gotten the same attention?

The half nobody is built for: trusted infrastructure exploitation

In delivery abuse, the platform carries someone else's payload. In exploitation abuse, the platform generates the payload itself.

The attacker registers a free account on a real SaaS service - Amazon, a calendaring product, an invoicing tool. They find a user-controlled field that gets rendered into transactional email: the profile name, the listing title, the invoice memo, the event description. They write the lure into that field. Then they trigger the platform's own workflow.

The platform takes the attacker's string and runs it through its templating engine. The result is a transactional email - a security alert, a booking confirmation, a meeting invite - rendered from a real template, signed with the provider's DKIM key, and sent from the provider's own SES or equivalent. Every authentication check returns green. Every reputation lookup returns green. The malicious bytes are authored, rendered, signed, and delivered by a real provider.

A campaign we investigated last month illustrates the pattern. The attacker registered an Amazon account and entered in the "First Name" field, a string ending in a callback number. They added a ProtonMail group as the contact email and a Microsoft 365 tenant as a downstream forwarder. They triggered a routine Amazon security event. Amazon rendered the attacker's string into the greeting slot of its own template and emitted a fully authenticated alert from account-update@amazon.com. 

Proton forwarded the message once; M365 redistributed it to the real victim list with SRS rewriting the envelope so SPF passed at every recipient gateway. Amazon was the generator. Proton was the off-ramp. Microsoft was the fanout. The attacker wrote eleven digits and owned the rest of the message structurally for free.

There is nothing to detonate here. No malicious attachment to sandbox. No shared document to retrieve. The lure exists directly inside the authenticated body of the email, and the only infrastructure the attacker controls is an account on a service most enterprises cannot realistically block.

Delivery and exploitation do not share the same defense model 

Delivery defense lives outside the email. The attack reveals itself when you follow the link, detonate the file, score the page the share resolves to. The malicious content is eventually reachable, and the discipline is to reach it.

Exploitation defense has no outside. Most times, there is nothing to follow. The attack reveals itself inside the rendered body - in the gap between what a real Amazon security alert is supposed to communicate and what this particular alert is actually asking the user to do. The signal lives in the structure of the message itself, not in any artifact it points to.

Reputation, authentication, and URL scanning all answer questions about the envelope: who sent it, was it signed, and where does it point. Exploitation puts the lure where none of those questions reach. A stack that bolts a sandbox onto a reputation engine has addressed half a category and called it done.

What changes when you see the category clearly

The analytical move for exploitation is to stop grading the sender and start reading the message against the platform's template baseline.

What does a real Amazon security alert normally communicate? What does a real Airbnb reservation confirmation typically look like? Where does the rendered intent of this message diverge from those expectations? 

That signal can then be stitched across messages, so an industrialized campaign surfaces as one operation rather than dozens of unrelated ghosts.

This is a different muscle from delivery defense. Stacks built for one are not, by accident, built for the other.

What’s next?

Trusted infrastructure exploitation is likely to accelerate as more SaaS platforms expose customizable templating surfaces to end users. Every single field that gets rendered into a legitimate transactional email—from a "Reason for request" box to a custom "Project Name" is a candidate for a malicious payload.

We are already seeing this pattern rotate across various providers in our pipeline. When one platform tightens its controls, the attackers simply shift their automation to the next reputable service with a free tier and a notification engine.