Aged Domain, Cloud Rail, Fake Portal: How a Compromised 1998 Domain Delivered an EFT Credential Harvest via Amazon SES

The message told a business officer at a university that an EFT remittance receipt was ready for review. To view it, she needed to open the Access Portal. The link said "Access Portal." It did not go to a portal.

The sending domain had been registered since 1998. Amazon SES delivered it. SPF, DKIM, and DMARC all passed. Exchange Online Protection assigned it a spam confidence level of 1, the low end of the scale, and placed it in the inbox.

Three staff members received variants of the same message within a twenty-minute window. Automated systems resolved it as phishing before any of them clicked through. But the infrastructure used here merits a close read, because nothing about the delivery path looked wrong until you examined where the links actually pointed.

The lure and the sender construction

The subject line referenced an eSign document with a machine-generated reference ID embedded in the filename, a format that mimics automated document-management notifications. The body invited the recipient to open an Access Portal to view an EFT remittance receipt, a common enough workflow in university finance and administrative offices.

The from address was built to look like a service account: a NoReply address at the compromised domain, with a local-part structured as a portal notification alias. Nothing in the visible sender string flagged the address as attacker-constructed. The display name matched the local-part format, so no impersonation mismatch appeared in the From field.

This is the ESP abuse playbook applied to a compromised account scenario. The attacker did not register a fresh domain. Instead, they accessed an aged legitimate domain and used it as the sending identity, routing the message through Amazon SES so that the outbound IP carried the cloud provider's established reputation rather than an unknown hosting address.

The combination is intentional. Domain age and cloud-provider relay are the two signals most gateway filters weight most heavily in reputation scoring. Combining both, alongside full authentication, creates a message profile that passes nearly every heuristic designed for fresh attacker infrastructure.

Authentication passed on a compromised legitimate domain

The compromised domain has been registered since 1998 and is held through Network Solutions with a renewal out to 2028. That age matters: reputation systems that deprioritize young domains treat it as an established, low-risk sender.

The relay chain confirms Amazon SES as the outbound infrastructure. SPF passed for the SES IP. DKIM passed with two valid signatures, one for the compromised domain and one for amazonses.com. DMARC passed for the header From domain. Composite authentication scored a perfect result.

None of that tells you the domain owner sent the message. Authentication confirms that the message used infrastructure the domain owner had configured or that an attacker had reconfigured after compromise. The checks cannot distinguish between authorized use and a compromised account using valid credentials to push mail through SES.

The credential harvesting goal is visible in the link architecture. What looked like a single portal link was actually three separate destinations pointing at different stages of a capture flow.

Three links, three destinations, one mismatch pattern

The Access Portal button resolved to two different actual URLs depending on which copy of the message the recipient received. One resolved to realdcos[.]guneymarmarazemin[.]com, a subdomain on an unrelated Turkish domain with no legitimate connection to any accounts-payable or EFT service. The second resolved to medium[.]com, a legitimate publishing platform, included as a decoy to produce a clean scanner verdict for one of the two Access Portal hrefs.

A fourth link pointed to 1stdirectory[.]co[.]uk/account/confirmemail/ with an encoded token and a userid parameter. A business directory's account-confirmation endpoint has no legitimate role in an EFT remittance workflow. The structure, an encoded token plus a userid, matches what a credential-capture flow uses to track which target clicked and associate the submission with a specific identity.

The displayed link text across all Access Portal links was the same: "Access Portal." A recipient reading the email saw one consistent label and no reason to inspect the underlying href. Scanners comparing the displayed text against the destination domain flagged the mismatch. Human readers without that comparison layer had no visible indicator.

The fake login pages at the attacker-controlled subdomain and the directory confirmation step together form a two-stage capture: the subdomain harvests credentials, and the directory confirmation step validates that the specific target interacted with the flow.

Why the inbox delivery path was clean

The message reached the inbox with an SCL of 1. That score reflects the evaluation at the Microsoft Exchange Online Protection layer: the sending IP (a known Amazon SES address), the authenticated sending domain (a 27-year-old legitimate domain), full SPF/DKIM/DMARC, and no content-level signatures matching known spam patterns at filter time.

The HTML quality issues in the body, including repeated block structures and a malformed template fragment, are common in campaigns that stitch together components from multiple phishing kits. Those are visible to content parsers that look for them, but they do not automatically trigger a spam verdict without corroborating signals. The Microsoft antispam headers show no category beyond an anomalous safety flag (SFTY:9.25), which indicates a potential phishing signal was present but not sufficient to move the SCL.

This is the gap that IRONSCALES data consistently surfaces: our Adaptive AI evaluates the full behavioral context, including the displayed-versus-actual link comparison, the sender-to-recipient history showing no prior correspondence, and the financial-urgency pattern in the message body, rather than relying on infrastructure reputation alone.

Indicators of compromise

What caught it

The message passed gateway filtering. Microsoft delivered it with a low spam score. The delivery path looked clean by every infrastructure measure.

What resolved it as phishing was behavioral analysis at the point of arrival: the sender had no prior relationship with the recipients, the displayed link text did not match the actual destinations, and the subject-line pattern matched known phishing reference-ID formats. Automated systems resolved all three affected mailboxes as phishing within minutes of delivery, before any recipient opened the portal link.

The industry-level picture reinforces the detection gap. Verizon's 2026 Data Breach Investigations Report places phishing in 16 percent of initial-access cases. Microsoft's 2024 Digital Defense Report documents the growing reliance on cloud-provider infrastructure for phishing delivery, exactly because provider reputation absorbs the reputational cost that fresh attacker domains would otherwise incur. CISA's phishing guidance recommends verifying any financial or credential request through a known, independent channel before acting.

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

A secure email gateway scores this message on infrastructure. An aged domain, a trusted cloud relay, full authentication, no payload attachment, links to a legitimate platform: the profile is favorable. The fraud sits in the href the recipient never sees, pointing to a subdomain the recipient has no reason to know.

The Access Portal was not a portal. It was a collection point. The link text was the only part of it that was legible.