A 2019 Credential Request, Two Dev Subdomains, and ARC That Couldn't Save the Auth Chain

The email arrived from john@sportssystems[.]com, sent through Amazon SES. The subject referenced a credential request from 2019 for a college bowl game event. The message asked the recipient to confirm their login credentials for the event's platform account.

At Mimecast, the email looked clean. DKIM passed. DMARC passed. ARC seals were applied to preserve those results for the next hop.

At Microsoft 365, the picture changed. SPF failed. DKIM failed. DMARC failed. The message was quarantined by policy.

In between those two results was a relay chain, a broken alignment, and a credential harvest form sitting on a -dev subdomain that had no business appearing in an external email.

What Mimecast Saw and What Microsoft Saw

Amazon SES sent the message from IP 76[.]223[.]145[.]186. Mimecast received it at 170[.]10[.]132[.]61. At Mimecast, DKIM passed under the signing domain and DMARC passed by alignment. Mimecast applied ARC seals to the message before forwarding it to Microsoft 365.

ARC (Authenticated Received Chain) is designed for exactly this scenario. When an intermediary mail server receives a message with passing authentication and then forwards it, the original alignment can break because the forwarding IP is no longer the original sender IP. ARC preserves the original authentication results as a signed chain that the final receiving server can inspect. If the final server trusts the ARC intermediary, it can honor the original passes even when re-evaluation at its hop fails.

Microsoft 365 saw the opposite result. SPF failed because the forwarding IP did not align with the SPF record for sportssystems[.]com. DKIM failed at Microsoft's evaluation step. DMARC failed as a consequence of both. Microsoft's ARC processing either did not trust the Mimecast intermediary or the ARC chain did not satisfy the configuration requirements for the receiving tenant. The result was a quarantine by policy.

This is a real operational tension in email authentication. ARC works when the receiving server has an established trust relationship with the intermediary. When that trust is absent, the ARC chain records what happened but does not change the outcome.

The Dev Subdomain Problem

The credential request in the email linked to two hostnames: app1-dev1-secure.sportssystems-dev[.]com and app1-dev2-secure.sportssystems-dev[.]com. Both used the -dev naming pattern. Neither was a production hostname.

sportssystems-dev[.]com was registered November 23, 2021, through GoDaddy, with AWS nameservers. This is a separate domain from sportssystems[.]com. A -dev suffixed domain registered by a third party on GoDaddy with AWS nameservers is not a legitimate development subdomain owned by the company. It is a registrant-controlled lookalike domain using the dev naming convention to appear affiliated with the real platform.

The login endpoint on these subdomains was login.cfm, a ColdFusion credential submission form. This is the credential harvesting payload. A recipient who clicked the link, arrived at a page that looked like the platform login, and entered their credentials would be handing them directly to whoever controls sportssystems-dev[.]com.

Using a -dev suffix has a secondary benefit for the attacker. Security teams and automated tools may apply different trust thresholds to dev infrastructure, either giving it more latitude (assuming internal traffic) or less attention (assuming it is test/sandbox and not production-critical). Neither assumption is correct for a domain controlled by an unknown registrant.

Template Errors as a Campaign Signal

The email contained two visible production defects: empty Organization fields that should have been populated with the event or account name, and duplicated text blocks that suggest a merge or template rendering error. These are consistent with an email generation system that was not properly configured before the campaign was launched.

The event referenced in the email was a 2019 credential request for a college bowl game event. Using a years-old credential request as the lure accomplishes two things. It references an account the recipient may have forgotten, making it harder to dismiss as clearly irrelevant. And it avoids the scrutiny that a current-event credential prompt might attract. A request to "confirm your 2019 credentials" is easy to overlook as routine platform maintenance.

The contact email for the event in the message was eric@novaarizonabowl[.]com, pointing to a college bowl game event's domain. Multiple Mimecast URL Protect rewrites were applied to the links in the email, indicating the Mimecast environment had its own link-rewriting configured, adding a further layer between the recipient and the final destination URL.

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

The Detection Case

Microsoft's policy quarantine caught this message, but the detection path was indirect. The quarantine was triggered by the triple authentication failure at the Microsoft hop, which was itself a consequence of the relay chain breaking alignment. Had Mimecast been the terminal relay (had the recipient's mailbox been hosted in Mimecast rather than Microsoft 365), the message would have passed all authentication checks at the final hop and been delivered.

Behavioral signals that an Adaptive AI evaluation would surface independently of authentication: a sending domain with a -dev pattern in the link targets; a credential request dated six years prior; template errors indicating a poorly configured campaign; a login.cfm endpoint on a non-production subdomain; and a tracking pixel (control3/et.cfm) embedded in the email to confirm delivery and opens.

The combination of these signals, a real platform abused as a sending identity, a lookalike dev domain as the payload host, and a multi-year-old lure designed to appear as routine account maintenance, represents a campaign built for plausible deniability at every layer.

Indicators of Compromise

MITRE ATT&CK Mapping