The Link Said Mail. The Click Hit a Cloud Bucket

A message lands in the inbox of a marine-electronics company. It warns that the mailbox has exceeded its storage quota and will stop receiving mail within hours unless the user validates the account. The link text spells out the company's own familiar mail domain in plain letters. Every visual cue says this is routine housekeeping from the mail platform. The recipient hovers, sees the trusted name, and reaches for the click.

The trouble is that link text and link destination are two entirely different things. What the eye reads and what the browser loads are set independently, and a phishing kit controls both. In this case the visible text pointed one place and the actual destination pointed somewhere else entirely: a live credential-collection form parked inside a cloud-storage bucket.

What the recipient saw

The lure leaned on urgency and familiarity, the two oldest levers in social engineering. A storage-quota warning is mundane, expected, and easy to act on without thinking. That is the point. According to the 2024 Verizon Data Breach Investigations Report, phishing is present in 15% of breaches, and the human element factors into 68% of them. Attackers do not need a clever exploit when a believable pretext and a trusted-looking link will do the work.

The displayed link text read as the company's own mail domain. Nothing in the visible message hinted at the destination. There was no misspelled brand, no obvious lookalike, no garbled sender name to catch the eye.

Where the click actually went

The href behind that trusted text resolved to an object-storage bucket on the IONOS cloud platform. The sign-in form served from that bucket was live, styled to resemble a mail-provider login, and confirmed operational by a screenshot of the running page.

The most telling detail was in the query string. The URL carried a base64-encoded parameter that decoded to the recipient's exact mailbox address. That single design choice turned a generic harvest page into a personalized one. Before the target typed a single character, the page could pre-load their identity so the fake login looked pre-filled and specific to them. Personalization lowers suspicion and raises submission rates, and it signals a phishing kit built to scale across a recipient list, one encoded mailbox at a time. Hosting on mainstream cloud storage adds a second advantage: the domain is broadly trusted, carries a valid certificate, and rarely sits on a reputation blocklist.

Why authentication passing proved nothing

Here is where this case earns study. The message passed DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication Reporting and Conformance (DMARC). A quick reading of those results says trustworthy. A careful reading says the opposite.

DKIM and DMARC passed for evolutionsdubai[.]com, the domain that actually sent the message. That domain was registered roughly three weeks before the send, with WHOIS registration details redacted. The attacker owned it, signed from it honestly, and aligned it correctly, so the checks came back green. What passed was the attacker's own three-week-old domain, not the marine-electronics brand the email pretended to be. Sender Policy Framework (SPF) told a different story, returning a PermError from an invalid mechanism on the originating IP address 217[.]160[.]120[.]242, geolocated to Germany.

Authentication answers a narrow question: was this message honestly signed and aligned by the domain that sent it? It does not answer whether that domain has any right to represent the brand it names, or whether the sender means you harm. The Microsoft Digital Defense Report 2024 documents the same pattern across the landscape: identity and email-based attacks routinely satisfy technical controls while defeating the human reading the message.

Mapping the attack to MITRE ATT&CK

The tradecraft maps cleanly to the MITRE ATT&CK framework.

Indicators of compromise

All indicators are defanged. Do not click or requery them in a live environment.

How to catch a link that lies

The defensive lesson is to stop treating a green authentication result as a verdict on trust. Several signals in this message were catchable without ever resolving the payload.

The clearest was the mismatch between displayed link text and resolved destination. A control that compares the two, rather than reading only what the eye sees, would have flagged this immediately. The destination itself was a second signal: a login form served from a raw object-storage bucket is rarely how a real mail provider asks you to validate an account. A third was the domain's age, since a sender domain registered weeks before contact is a well-worn marker of credential-harvesting infrastructure.

This is the terrain where behavioral analysis outperforms rule-based filtering. Themis, the Adaptive AI engine inside the IRONSCALES platform, weighs sender history, link behavior, and content intent together, so a message can be honestly signed and still be judged hostile on the evidence that matters. CISA reaches the same conclusion in its phishing guidance: resilience comes from layered technical controls plus trained people, not from any single check.

The takeaway

A passing DKIM and DMARC result tells you a message was honestly signed. It does not tell you the signer is who the message claims to be. When the domain doing the signing is three weeks old and the link text says one thing while the href loads a credential form in a cloud bucket, the authentication result is not reassurance. It is the disguise. Read the destination, not the display, and judge the sender by behavior rather than by the color of a checkmark.

See how IRONSCALES stops credential harvesting before the click at credential-harvesting protection.