When the Sender Domain Is Also the Phishing Kit Host: Dual-Purpose Domain Compromise

# When the Sender Domain Is Also the Phishing Kit Host: Dual-Purpose Domain Compromise

The email came from a real company. The domain had been registered since 1997. SPF passed. DKIM passed. DMARC passed. The sending infrastructure was Amazon SES, a legitimate cloud email service. Every authentication signal said: this is fine.

It was not fine. The attacker had compromised the domain and used it for two things at once: as the authenticated sending identity and as the server hosting the credential harvest page. When the victim clicked "View Content," they were not leaving the domain. They were going deeper into it.

The Setup: Impersonation Built on a Foundation of Real Infrastructure

The email arrived in a Microsoft 365 inbox on March 27, 2026. The subject line read: "Human Resources has shared you 'Open Enrollment' Document." The sender display name was "Docsend," and the from address was accounting@[compromised-manufacturing-domain].com.

The body impersonated Dropbox DocSend with precise visual fidelity. It used the DocSend color palette, Roboto font stack, and footer structure. A blockquoted message from "Human Resources Department" told the recipient: "you are yet to complete your open enrollment session, today is your last chance to do so. Our last session is at 11 PM MDT."

That deadline is the threat vector. Open enrollment is time-sensitive, HR-adjacent, and credible to almost any employee. The 11 PM MDT cutoff was specific enough to feel real without being verifiable. It exists entirely to reduce scrutiny and accelerate the click.

The call to action: a single dark button labeled "View Content."

Two Roles, One Compromised Domain

Most compromised-domain attacks focus on one abuse vector: either the attacker sends mail from the hijacked domain, or they host a phishing kit on the hijacked domain. This attack used both.

The compromised domain was the From address. It was also the landing page host. Every hop in the attack chain touched the same legitimate domain name.

Here is the full sequence:

1. The attacker gained access to the victim domain's Amazon SES configuration. This means they either compromised the domain owner's AWS account or obtained SES sending credentials. Either way, they verified a sending identity for the domain and added a DKIM signing key.
2. The phishing kit was deployed to a subdirectory of the domain: /secure/open.php?token=[unique token per recipient]. This is a standard token-based harvest page pattern. The token personalizes the page and tracks which recipient followed the link.
3. The phishing email was sent through SES. The Authentication-Results header confirms: spf=pass, dkim=pass for the domain, dkim=pass for amazonses.com, and dmarc=pass with action=none. Microsoft Defender passed it to the inbox.
4. The email body contained two link elements pointing to the same destination. The first was a direct URL to the harvest page on the compromised domain. The second was wrapped in an AWS click-tracking redirect (kxqdm4d2.r.us-east-2.awstrack.me) before resolving to the same harvest page.

The awstrack.me wrapper is SES's built-in click tracking. It is legitimate infrastructure that also adds a layer of indirection, routing the visible link through an Amazon-owned domain before landing on the harvester.

Why Authentication Is Not a Trust Signal Here

Email authentication protocols answer one question: was this message authorized by the domain it claims to be from? SPF checks the sending IP. DKIM verifies the signature. DMARC enforces alignment between the authenticated domain and the From header.

None of those checks ask whether the domain owner intended to send this email. None verify whether the link destination matches the claimed brand. When a domain is compromised, every authentication mechanism operates exactly as designed. The attacker is technically an authorized sender. The phishing attack exploits one assumption: that authentication equals legitimacy. It does not.

The Verizon 2024 Data Breach Investigations Report identifies stolen credentials as involved in more than half of all breaches. Attackers have clear incentive to find delivery paths that authentication-based defenses are configured to trust. Compromising a legitimate domain's email infrastructure is the logical endpoint of that strategy.

The Technical Chain: Defanged IOCs

The DKIM signature key used was uffpygdgwyodp4gpdemcxwxyh4akv2xy._domainkey.caldwellmfg[.]com. If that key remains active in DNS, the sending infrastructure is still operational.

The harvest page sits at /secure/open.php. That path does not exist in DocSend or Dropbox infrastructure. A legitimate DocSend share resolves to docsend.com. The brand claim and the link destination are completely mismatched, which is the clearest indicator available from a content analysis perspective.

MITRE ATT&CK Mapping

This attack maps to MITRE ATT&CK techniques across the initial access and resource development phases:

• T1586.002 - Compromise Accounts: Email Accounts: Attacker compromised the domain's SES configuration or AWS account to enable authenticated sending.
• T1566.002 - Phishing: Spearphishing Link: Delivery mechanism. A link-based lure targeting a specific recipient with personalized token.
• T1078 - Valid Accounts: The attacker operated as an authorized SES sender for the compromised domain.
• T1598.003 - Phishing for Information: Spearphishing Link: The credential harvest page is designed to capture and exfiltrate credentials.

CISA has documented the pattern of attackers using trusted infrastructure to bypass perimeter defenses. This is that pattern.

What Defenders Need to Know

Authentication-based filtering cannot catch this attack class. An email that passes SPF, DKIM, and DMARC is not necessarily safe. It is only authenticated. Those are different things.

Effective detection requires behavioral and content-based signals that work regardless of authentication status:

Brand-domain alignment checking. The email claims to be from Dropbox DocSend. Every link resolves to a manufacturing company domain. No legitimate DocSend notification links to a manufacturing company's web server. Any system that compares claimed brand identity against actual link destinations flags this immediately.

Anomalous sender history. This was a first-time external sender to the recipient organization. Combined with other indicators, that raises the risk profile significantly.

Link path analysis. The path /secure/open.php on a manufacturing company domain is not a normal business asset. Harvest pages frequently use generic paths like this precisely because there is no legitimate content to compare against.

Community threat intelligence. Themis correlated this email with previously resolved phishing incidents at other organizations using similar patterns. That community signal is unavailable to any defense that only evaluates the current message in isolation.

According to IBM's X-Force Threat Intelligence Index 2024, phishing accounts for 41% of all initial access vectors. The attacks that bypass perimeter defenses share one trait: they use infrastructure that perimeter defenses are configured to trust. A compromised legitimate domain is the clearest possible example.

The email was quarantined before credentials were captured. But it cleared every authentication gate. For any organization treating authentication pass/fail as a meaningful trust signal, this attack is invisible until it is not.

See how many phishing emails are getting through your filters.

---

Threat intelligence sourced from the IRONSCALES Threat Intelligence library. IOCs defanged for safe reference. Case observed March 27, 2026.