Access Denied (To Scanners Only): A Presigned S3 Link

The message had a one-word subject: "Print." It arrived from an iCloud address the recipient, an HR specialist at a U.S. municipal government, had never heard from. Inside was a link to a document. The link pointed at Amazon S3, carried a valid TLS certificate, and resolved cleanly when a human clicked it.

When the email security scanner tried to fetch the same object, it got back HTTP 403 Access Denied.

That gap, one response code for the victim and a different one for the machine, is the entire attack. The payload lived behind a presigned AWS S3 URL, and presigned URLs are built to behave exactly this way.

A Link That Says 403 to Robots and 200 to People

A presigned S3 URL is a temporary, cryptographically signed link that grants access to a private object for a fixed window. You have seen the shape of one: a long amazonaws.com address trailing AWSAccessKeyId, Expires, and Signature parameters. The signature authorizes a specific request, and the Expires value sets a hard deadline. After that moment, or if the request does not match what was signed, S3 answers with a 403.

Attackers get two things from this. The first is reputation laundering. The object sits on s3.us-west-2.amazonaws.com, a domain no reputation engine is going to blocklist and no DNS filter is going to flag. In this case the payload rode in on a legitimate-looking case-management storage bucket, so there was no attacker domain to catch.

The second is a scanning blind spot. Email security tooling fetches a URL to inspect what it serves. But a scanner rarely fetches at the same instant the victim clicks. It fetches on its own schedule, sometimes minutes or hours later, sometimes with a request that does not reproduce the signed original. By the time it reached out, the presigned window had lapsed and S3 returned 403 Access Denied with an XML error body. There was nothing to render, nothing to detonate, nothing to score. In our analysis the scanner could not retrieve the object at all, so the file behind the link was never inspected. The victim's browser, clicking inside the valid window, would have had no such problem.

A scanner that cannot download an object cannot rule it malicious. And "cannot rule it malicious" is far too often treated as "clean."

Why a First-Time iCloud Sender Passed Authentication

The email was sent from a real Apple iCloud account using iPhone Mail. That detail matters, because it means the message authenticated perfectly. SPF passed (the sending IP was a genuine iCloud outbound relay), DKIM passed with an icloud.com signature, and DMARC passed with compauth=100. The recipient organization's secure email gateway scored the message as not spam, with a phishing score of zero.

None of that is a failure of authentication. It is a reminder of what authentication actually proves. SPF, DKIM, and DMARC confirm that a message was sent by the domain it claims and was not altered in transit. They do not vouch for intent. An attacker who signs up for a free iCloud account, or who takes over an existing one, sends fully authenticated mail by definition. Authentication tells you the letter is real. It does not tell you the person who wrote it is honest.

What the record did show was a cluster of behavioral signals: a first-time external sender, no prior correspondence with the recipient, and a sender the platform had already flagged as high risk. Themis, the IRONSCALES agentic AI SOC analyst, weighed those signals rather than the passing auth stamps and the unreadable link, and flagged the message for credential theft. You can see how Adaptive AI and behavioral detection work when the usual verdicts come back empty.

The Layers Around the Link

The link was not sitting alone in the body. The attacker wrapped it to look like routine system output.

• Subject "Print": A single word that mimics a scan-to-email or printer job, the kind of automated message an HR mailbox sees constantly and barely reads.
• A nested message/rfc822 attachment: A small embedded email object that the incident tooling tried and failed to fully extract. Nested messages can hide follow-on links and images from inspection, and this one resisted analysis.
• An Outlook preview wrapper and an aka.ms link: Microsoft's own preview and Safe Attachments explainer artifacts, which make the whole thing read like a forwarded, already-processed message rather than a cold pitch.

Stack those together and you get an email that looks handled, benign, and boring. That is the point.

Attack Chain and MITRE Mapping

• Initial access, spearphishing link (T1566.002): The core delivery mechanism was a link to an externally hosted document. See MITRE ATT&CK T1566.002.
• Spearphishing attachment (T1566.001): The nested message/rfc822 object added a second, unscannable payload surface. See MITRE ATT&CK T1566.001.
• Defense evasion: The presigned URL's time-boxed signature turned "scan the destination" into a 403, and legitimate AWS hosting suppressed reputation and DNS signals.

Email remains the front door. The 2024 Verizon Data Breach Investigations Report found phishing present in 15 percent of breaches, and stolen credentials involved in 38 percent. Credential theft is not cheap when it lands: IBM's Cost of a Data Breach report puts phishing among the most expensive initial vectors.

Closing the Unscannable-Content Gap

The fix is not another URL blocklist. It is a change in how a "clean" verdict gets earned.

• Treat unfetchable as unresolved. A 403, a timeout, or an expired presigned link is missing evidence, not a passing grade. Route those messages to behavioral scoring instead of releasing them.
• Weight sender behavior. A first-time external sender emailing an HR mailbox a bare document link deserves scrutiny that a passing DMARC record will never provide. This is textbook credential harvesting staging.
• Layer detection past the gateway. Authentication and reputation are necessary and insufficient. Behavioral analysis catches what a single URL verdict cannot. CISA's phishing guidance makes the same case for defense in depth.

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

If your stack still treats "the scanner could not open it" as "the scanner found nothing wrong," a presigned link is all an attacker needs. That blind spot is exactly the kind of gap SEG augmentation is meant to close, and it is where behavioral signals earn their keep.

Indicators of Compromise

One More Thing

Presigned links are not going away. They are a legitimate, widely used AWS feature, which is precisely why they make such durable cover. The question to ask your email security is simple: when it cannot read the file, what does it decide?