Seven Days Old, Port 8443: The Throwaway Domain That Safe Links Couldn't Stop

A Compromised University Account, a Known Name, and a Domain That Didn't Exist Yesterday

On April 8, 2026, an email with the subject line "Re: Appointment on Monday" arrived in the inbox of a professional at a North American design firm. The display name matched a known external contact. SPF passed. DKIM passed. DMARC passed. Microsoft's composite authentication returned compauth=pass reason=100, its highest confidence score.

The actual sending address was a student account at a Mexican public university. The single link in the body, wrapped by Microsoft Safe Links, decoded to a domain registered that same morning on a non-standard port: 8443.

The email body read like a casual note between acquaintances: "I wasn't intending to trigger any memories in any way, just found and wanted to share these photographs." One link. No attachments. A curiosity lure calibrated to bypass content-based scanning by saying almost nothing at all.

The Infrastructure Was Built to Be Burned

The attacker operated from a compromised Microsoft 365 student account at a public university in central Mexico. The account, a374859@alumnos[.]uaslp[.]mx, was a student mailbox. Because Microsoft's own infrastructure handled sending, the message inherited full authentication from Microsoft's relay chain. The DKIM signature verified under uaslpedu.onmicrosoft.com. SPF aligned against the Microsoft outbound protection IP (2a01:111:f403:c111::9). ARC headers showed clean chain validation across two Microsoft hops.

According to the Microsoft Digital Defense Report 2024, compromised education-sector accounts are among the most frequently abused for phishing relay because .edu tenants often lack conditional access policies and MFA enforcement that enterprise environments mandate.

The payload domain tells a sharper story. hvdxrsausc[.]com was registered on April 8, 2026, at 07:59:18 UTC through Namecheap. The phishing email was sent at 13:53:03 UTC the same day. That is a six-hour window between domain creation and delivery. WHOIS records are privacy-shielded through Withheld for Privacy ehf (Iceland). The domain's nameservers, ns1.ploegonpedns[.]com and ns2.ploegonpedns[.]com, point to a self-hosted DNS domain that was itself registered just two days earlier (April 6, 2026) through the same registrar with the same privacy service.

This is infrastructure designed for a single campaign. Register a throwaway DNS domain on Day 0. Register the payload domain on Day 2. Send phishing emails within hours. Abandon everything before reputation systems catch up. The FBI's 2024 Internet Crime Report documented $2.9 billion in BEC losses driven by exactly this kind of disposable infrastructure rotation.

Port 8443 and the Limits of Safe Links

The phishing URL embedded in the email was wrapped by Microsoft Safe Links:

hxxps://can01[.]safelinks[.]protection[.]outlook[.]com/?url=hxxps%3A%2F%2Fjfedp[.]hvdxrsausc[.]com%3A8443%2FAdoBVCWr

Safe Links decoded the destination to hxxps://jfedp[.]hvdxrsausc[.]com:8443/AdoBVCWr. The X-MS-Exchange-AtpMessageProperties header confirmed Safe Links processing (SA|SL). The link received a "Mixed Result" verdict from the IRONSCALES scan, and Safe Links itself did not block the decoded URL at the time of analysis.

Port 8443 is significant. It is the standard alternative HTTPS port, commonly used for web application servers, admin panels, and development endpoints. Many URL filtering systems focus inspection on ports 80 and 443. Traffic on 8443 can evade automated sandbox crawlers that do not resolve non-standard ports. It also suggests the attacker was running a lightweight credential harvesting page on infrastructure not intended for long-term hosting.

The MITRE ATT&CK framework classifies the domain registration under T1583.001 (Acquire Infrastructure: Domains). The phishing delivery maps to T1566.002 (Spearphishing Link). The compromised university account maps to T1586.002 (Compromise Accounts: Email Accounts). The display name manipulation maps to T1036.005 (Masquerading: Match Legitimate Name or Location).

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

The Display Name Did the Heavy Lifting

The From header displayed a name that matched a known external contact in the recipient's communication history. The IRONSCALES platform flagged this as an exact display name impersonation: the system recognized the name from prior legitimate correspondence sent from a completely different email address. The attacker did not guess. They selected a name that would register as familiar the moment the recipient glanced at their inbox.

This is the core problem with authentication-only defenses. SPF, DKIM, and DMARC answered the question "Did this email come from alumnos.uaslp.mx?" The answer was yes. They cannot answer "Is this person who they claim to be?" That question requires behavioral context: sender history, relationship mapping, communication patterns. The Verizon 2024 Data Breach Investigations Report found that the human element contributed to 68% of breaches. Display name impersonation exploits exactly that element.

Microsoft's anti-spam filters did assign an SCL score of 5 (spam threshold) and an SFTY code of 9.25 (impersonation safety tip). The email landed in the recipient's Junk folder with a spam categorization. But SCL 5 is a threshold decision, not a conviction. A slightly more polished email body, a warmer sender history, or a different recipient configuration could shift that score below the cutoff.

IRONSCALES Themis classified the email as credential theft with a VIP recipient tag and flagged the impersonation pattern. The combination of a known display name originating from a mismatched domain, a nostalgia-based curiosity lure, and a freshly minted destination domain created a signal cluster that authentication headers alone could never surface. The incident was quarantined within four minutes of delivery.

Disposable DNS Is the Red Flag Your Filters Are Missing

This attack combined three elements that individually might not trigger an alert but together form a reliable threat signature: a compromised .edu account providing clean authentication, an exact display name match exploiting relationship trust, and a same-day domain on a non-standard port hosting the credential page.

Defenders should query mail logs for inbound messages where the display name matches a known contact but the sending domain does not match any previous correspondence. Domain age checks should apply to decoded Safe Links destinations, not just the visible URL. Any destination on port 8443 (or other non-standard HTTPS ports) from a domain under 30 days old warrants automatic sandboxing, regardless of Safe Links status. And self-referencing nameserver domains (where the NS records point to a domain registered within the same week through the same registrar) are a strong indicator of throwaway attack infrastructure. CISA's phishing guidance emphasizes that authentication results should never be the sole basis for trust decisions. This case proves why.

The Infrastructure Trail