Failed Every Auth Check, Then Rode Google's Links to S3

The email arrived in a Financial Controller's inbox at a marine-electronics manufacturer. The sender was the Financial Controller. Same name, same address, the From field matching the To field exactly. It was a message the recipient supposedly sent to themselves, and it failed every authentication check an email can fail. Then it asked the recipient to re-activate their password.

Self-addressed spoofing is a blunt tool with a sharp psychological edge. A message that appears to come from your own account carries a borrowed sense of ownership. If it landed in your mailbox and it is from you, the instinct is that it must be routine. That instinct is exactly what this attack was built to exploit, and it did so while carrying a technical footprint that should have stopped it at the door.

A Message From an Account That Never Sent It

The infrastructure behind this message had no relationship to the domain it claimed to send from. The message originated from IP 45.59.104[.]196, an address with no PTR record, meaning no reverse DNS entry tied the IP to any hostname. Legitimate mail servers almost always publish a PTR record. Its absence here is a reliable signal of throwaway or misconfigured sending infrastructure.

Because that IP was not authorized to send on behalf of the spoofed domain, SPF returned a hard fail. There was no DKIM signature at all, so DKIM evaluated as none. With neither authentication method producing an aligned pass, DMARC failed, and the domain's published policy directed a quarantine action. The Microsoft X-Forefront-Antispam-Report header labeled the message CAT:SPOOF, an explicit spoof categorization.

Three authentication mechanisms exist specifically to answer the question this message posed: is this sender who they claim to be? All three answered no. The lesson worth internalizing is that DMARC enforcement at quarantine does not mean the message disappears. Quarantine routes failing mail to a junk or hold location, and recipients retrieve mail from those locations every day, particularly when the sender appears to be themselves.

Laundering an S3 Bucket Through Google's Own Redirectors

The call to action read RE-ACTIVATE SAME PASSWORD, a phrase engineered to feel like a low-stakes maintenance task rather than a credential handover. The link behind it is where the operator did their most deliberate work.

Rather than spoof a Google domain, the attacker chained the click through Google's own link services. The path began at meet.google[.]com/linkredirect, the redirect parameter built into Google Meet. From there it passed to a google[.]gg AMP URL, then to adservice.google.com[.]ph/ddm/clk, a Google ad-service click redirector. Only after traversing those Google-operated hops did the browser arrive at the actual landing page: cdn-storage-proxy-cloud-panel-fast-views.s3.us-east-1.amazonaws[.]com, an object hosted in an attacker-controlled Amazon S3 bucket.

Nothing in this chain spoofs Google. Every redirect hop is a genuine Google service being used as a laundering layer. A scanner or a human that inspects only the first visible link sees meet.google.com and stops worrying. The final destination, an S3 object with a deliberately reassuring name pattern (cdn, storage, proxy, cloud, panel), never surfaces in the displayed URL. This is open-redirect abuse in its cleanest form, and it is why treating a trusted outermost domain as proof of safety is a mistake. The domain you can see is not the page you land on.

Borrowed Legitimacy From a Footer That Did Not Belong

The message body included one more layer of theater. Pasted into it was a genuinely legitimate footer image lifted from a European university, OCR'd from its original context and dropped in as social-proof filler. The footer had nothing to do with the Financial Controller, the marine-electronics manufacturer, or password management. It was a real institutional graphic used purely to make the message feel more substantial to a skimming eye.

This is a recurring pattern in credential-harvest lures. Attackers borrow real, unrelated visual assets because a message that carries an official-looking image reads as more trustworthy than a message that is plain text. The relevance of the asset does not matter to the attacker. Its familiarity does.

MITRE ATT&CK Alignment

Indicators of Compromise

What Actually Catches This

Every static control that could have decided this message on reputation alone was set up to be fooled. The authentication verdicts were correct, but a quarantine action still puts the message within a user's reach. The visible link pointed at Google. The image looked institutional. What remained was the behavior.

A first-time, unauthenticated sending IP with no PTR, a self-addressed spoof pattern, a redirect chain that terminates on a consumer cloud-storage object, and a password-reset call to action are individually explainable and collectively damning. IRONSCALES Adaptive AI evaluates those signals in combination rather than trusting the outermost domain in a link or the folder a message was quarantined into. Themis, the Adaptive AI analyst, weighs sender novelty, self-send anomalies, and redirect-chain destinations together, which is precisely the correlation a single-layer gateway misses. According to the 2024 Verizon Data Breach Investigations Report, phishing accounts for 15 percent of breaches and the human element is present in 68 percent, and the Microsoft Digital Defense Report 2024 documents the continued industrialization of credential theft. Layered credential-harvesting protection closes the gap that trusted-domain reputation leaves open, and CISA's phishing guidance reinforces disrupting the attack before the click.

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

The Takeaway

This message told the truth about itself at the protocol layer and lied everywhere a human would look. It failed SPF, DKIM, and DMARC, and it was still built to be clicked, because the operator understood that quarantine is not deletion and that a Google-branded link is not a Google destination. Judge senders by behavior and links by where they actually resolve, not by the first domain you can read.