The Fake Approval Notice With a Console URL in Its Bucket

A shared internal mail-flow approvals alias at a supply-chain automation company received a message that appeared to be its own tenant talking to it. An approval had been requested, the notice said, over unusual sign-in activity on an account. The body carried Microsoft-styled chrome, a 48-hour window to verify access, and exactly one action: a Continue button. The whole thing arrived TNEF-wrapped, with a nested message/rfc822 attachment riding underneath it that scanned clean and could not be independently retrieved for deeper inspection.

The visible sender was not internal at all. It was a mailbox with a long numeric-looking local part on whyouhe[.]com, an external domain with no relationship to the recipient. Anyone who read that line had the answer in front of them. The trouble is that Reply-To and Return-Path had both been forged to a SystemMailbox address on the company's own onmicrosoft[.]com tenant, so the fields a mail client is most likely to surface on a reply pointed back inside the building.

The Approval Header That Kept the Real Sender

Approval requests are a genuine Exchange mail-flow feature, and that is exactly what made the pretext work. A moderated message generates a notice that arrives from the platform rather than from a colleague, so recipients are conditioned to see a system voice, an unfamiliar sender construction, and a single button, and to treat all three as normal.

The forgery was thorough in the fields people read and careless in the field a machine writes. Microsoft's own X-MS-Exchange-Organization-Approval-Requestor header still carried the true external address on whyouhe[.]com. The message asserted internal origin in Reply-To and Return-Path, then recorded external origin in the header trail. Those two statements cannot both be true, and reconciling them takes seconds once you know to look.

Authentication had nothing to say about the contradiction. SPF evaluates the envelope sender presented at delivery and DKIM evaluates the signing domain, while DMARC alignment under RFC 7489 is measured against the visible From domain. None of those mechanisms inspects Reply-To at all. The message travelled a standard Microsoft Exchange delivery path with no third-party relay or content-disarm hop to muddy the trail, which meant nothing looked structurally deformed on arrival. Header forgery of this kind is invisible to protocol checks by design, and stopping it depends on behavioral judgment layered over the platform, which is the case for Microsoft 365 augmentation rather than more authentication tuning.

The sender domain was quietly interesting too. It had been registered back in 2019, sat behind registrar privacy, and its WHOIS record had been updated in the days immediately before this campaign went out. That is the signature of a warehoused domain being brought back into service, and it defeats the crude heuristic of flagging newly registered senders. Age here was inherited, not earned.

A Bucket Name Dressed as the AWS Console

Following the Continue button is where this campaign separates itself from the ordinary. The final landing page was a static HTML object on Amazon S3, reached at s3[.]eu-north-1[.]amazonaws[.]com using path-style addressing. The bucket sitting in that path had been named eu-north-1[.]console[.]aws[.]amazon[.]comqwkjqlw90980, and the object inside it was called aut0sync[.]html, with a zero standing in for the letter.

Read that path the way a browser status bar shows it, truncated, on a phone, in the second before a click. The eye finds console[.]aws[.]amazon[.]com and stops. The actual host, the generic S3 endpoint, sits to the left of everything the reader focused on, and the random suffix that betrays the bucket sits to the right of it.

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

This is cheaper than any lookalike domain. There is no registration, no WHOIS record, no waiting period, and no certificate to obtain or mis-issue, because the connection is served under Amazon's own valid certificate for its S3 endpoint. A defender checking whether the destination is a real cloud provider gets a truthful yes. The deception lives entirely in a string an attacker was allowed to choose for free, which is why the object path itself has to be read as an indicator rather than skimmed for a recognizable brand.

Reputation Rented for the Middle Hop

Between the button and the bucket sat one borrowed hop. The Continue link resolved to a link-tracking subdomain belonging to monday.com, a real service on a real vendor hostname, carrying a signed token whose embedded destination parameter held the S3 address. Vendor link trackers forward whatever destination the link generator supplied, so the wrapper contributes reputation and a valid certificate while contributing nothing about where the browser actually lands.

Worth noting for anyone building detections on the hostname itself: that tracking subdomain resolved through Cloudflare, published Mailgun mail exchangers, and had no SPF, DKIM, or DMARC TXT records of its own. It is operational plumbing rather than a mail identity, so treating the hostname as reputable tells you about the vendor and nothing about the payload.

Mapping to MITRE ATT&CK

• T1566.002 Phishing: Spearphishing Link covers the delivery, a single button carrying an encoded destination into a targeted shared mailbox.
• T1656 Impersonation covers the pretext, an external message dressed as an internal platform notice through forged reply paths.
• T1583.006 Acquire Infrastructure: Web Services covers the landing page, hosted on a mainstream cloud object store with a deliberately deceptive object path.

Indicators of Compromise

What Actually Flagged It

No single artifact in this message was disqualifying on its own. The sending domain was years old and authenticated honestly. The redirector was a genuine vendor service. The landing host was genuinely Amazon. The attachment scanned clean.

What did not hold up was the combination. An external mailbox on an unrelated domain, claiming to be an internal system mailbox, sending an urgent sign-in review to a shared administrative alias, with its only action encoded inside a third-party tracker. Themis, our Adaptive AI analyst, returned a credential theft recommendation at 87 percent confidence with the Continue link flagged malicious, and the incident was automatically resolved as phishing. That is a relationship and intent judgment, not a signature match, and it is the layer credential harvesting protection has to operate on when every component is individually legitimate.

Speed is the reason it matters. The 2024 Verizon Data Breach Investigations Report puts the median time to click a phishing link at 21 seconds and to submit data at 28 seconds, with stolen credentials involved in 38 percent of breaches. A 48-hour deadline in the body was never the real clock.

The Takeaway

Three habits fall out of this one. Compare what the reader sees against what the platform recorded, because a forged reply path almost never survives a look at the mail system's own header trail. Read cloud object paths as strings rather than brands, since a bucket name is free, instant, and chosen by the attacker, and it will happily contain a hostname that belongs to someone else. And unwrap every redirect fully before verdicting a link, because a reputable wrapper describes the vendor that forwarded the click and never the address it forwarded to. CISA's phishing guidance (https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one) and NIST's definition of phishing (https://csrc.nist.gov/glossary/term/phishing) are useful anchors for both the pretext and the response.