The Phishing Email That Bypassed Every Filter
A targeted email reached a finance employee's inbox by abusing trusted cloud storage sending infrastructure, bypassing SPF, DKIM, and DMARC validation entirely.
Background
Most phishing attempts are noisy, badly written, and caught by email security tooling before they reach an inbox. This one wasn't. It arrived clean, passed every authentication check, and was visually convincing. The only reason it was escalated was that a cautious employee had a habit of hovering over links before clicking.
The target was in the finance department. The email appeared to come from a known vendor requesting review of an invoice attached via a shared document link. On the surface, nothing was wrong.
How It Bypassed the Filters
The attacker had created a free account on a major cloud storage and collaboration platform (one that the organisation used legitimately) and used the platform's built-in sharing notification feature to send the phishing message. Because the notification originated from the platform's own mail servers, it passed SPF, DKIM, and DMARC validation cleanly.
The email authentication controls worked exactly as designed. The problem was that they authenticated the sending infrastructure, not the intent of the sender. A legitimate platform's mail servers were being used as a launch pad.
The "invoice" link pointed to a page hosted on the same cloud platform, styled to mimic the vendor's branding, which then redirected to a credential harvesting page asking the user to "sign in to view the secure document."
Detection
The employee did not click the link but reported the email as suspicious. Their stated reason: "the vendor doesn't usually send me things via this platform, and the link felt off." No automated detection fired.
After the report, the email security platform was searched for similar messages and three other employees in finance had received variants of the same message over the prior 48 hours. None had clicked. The campaign had been running for two days before the first report came in.
Header analysis confirmed:
- Sending IP was the legitimate cloud platform's outbound mail relay
- SPF, DKIM, DMARC all passed
- The "Reply-To" header pointed to an attacker-controlled address (not visible to the recipient without inspecting headers)
- The redirect chain: cloud platform link to attacker landing page, hosted on a recently registered domain
Investigation
Confirmed that no credentials had been entered. Reviewed proxy logs for the attacker's domain and identified no outbound connections from corporate hosts. The campaign appeared to have failed, but the investigation continued to establish full scope.
The attacker's cloud platform account was reported to the platform's abuse team. The credential harvesting domain was blocked at the proxy and submitted to threat intelligence feeds.
A broader search across the past 90 days using the same "Reply-To" domain pattern identified one additional email four weeks earlier, also unanswered. The targeting appeared to be specifically focused on the finance team.
Remediation and Detection Improvement
The immediate actions were taken first. Then the gap was addressed: the email security platform lacked a rule for notifications from cloud collaboration services containing redirect chains to external domains. A rule was added to flag and quarantine emails from these platforms when the embedded links redirect to domains outside the organisation's trusted list.
The finance team received a targeted security awareness note describing this exact technique, with examples, without creating unnecessary alarm.
Outcome
No credentials were compromised. The detection gap was identified and closed. A new detection rule was added to the email security platform. Three variations of the same campaign targeting other organisations were found via threat intelligence sharing after reporting the IOCs.