The Login-Expiry Lure That Spoofed No One

Most phishing teardowns start with a lie about identity: a spoofed bank, a forged Microsoft notice, a display name borrowed from a colleague. This one is interesting precisely because it contains no such lie. An email reached two mailboxes at a multi-site outpatient physical rehabilitation therapy provider, and every authentication check a mail system can apply came back clean. SPF passed. DKIM passed. DMARC returned a pass. The attacker did not spoof anyone at all.

They did not need to. They owned the sending domain outright, had configured it correctly, and sent through reputable infrastructure. A gateway that leans on authentication had nothing to object to.

Authenticated Because They Wanted It To Be

The message came from info@corporacionludafa[.]com, carrying the display name MessageDesk, and it was relayed through Amazon SES out of the us-west-2 region. SPF passed on the sending IP, 54[.]240[.]27[.]205, which sits inside Amazon's published range. DKIM passed and aligned to the header domain corporacionludafa[.]com, with a second valid DKIM signature for amazonses[.]com layered on top. DMARC returned a pass with an action of none. Composite authentication came back clean, and the receiving edge assigned a spam confidence level of 1, effectively benign.

Every one of those checks did its job correctly. That is the uncomfortable part. Authentication proves that a server was authorized to send for a domain and that the body was not tampered with in flight. It proves nothing about the honesty of the content. When the attacker controls the domain and configures it properly, they simply inherit a clean verdict the same way a legitimate business would. There was no misalignment to catch, no failed signature, no forged header.

The sending domain itself is worth a note. corporacionludafa[.]com was not a same-day throwaway. It had been registered back in 2016 and was well aged, most likely a legitimate but long-dormant business domain that was repurposed or quietly taken over. An aged domain with a real registration history carries a cleaner reputation than a fresh one, which is exactly what makes it useful. Domain age, so often treated as a trust signal, worked in the attacker's favor here.

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

The Lure Was Bare on Purpose

The pretext was about as generic as credential-harvest email gets: a System Login Expiry Notice, warning that access was about to lapse unless the recipient acted. What stood out was what the message did not contain. No employer logo. No branded portal. No named IT administrator or help-desk contact. No reference number, ticket, or system that actually belonged to the recipient's organization. It was a template with the specifics filed off, the kind of notice that could be fired at any company because it claimed nothing about any particular one.

The visible body was nearly empty. Aside from Microsoft's own external-sender safety banner, there was almost nothing to read. The actual notice arrived as an attachment, and not an ordinary document. It was a nested email, a message/rfc822 file roughly 71 KB in size, named after the subject line so it read as System Login Expiry Notice - User ID [redacted]. The user-ID token in that filename was the recipient organization's own name, quietly personalizing an otherwise generic lure. Bundling the real pretext inside an attached message is a deliberate evasion. A gateway that scans the visible body and its links finds almost nothing to grade, because the credential-harvest content lives one layer down.

The outer file scanned clean, as expected. A nested email carrying a link or a form is not malware in the antivirus sense, and a static scan of the wrapper has little to flag until someone opens it.

Mapping to MITRE ATT&CK

The tradecraft maps onto the MITRE ATT&CK framework in two places:

• T1566 Phishing covers the core play: a socially engineered login-expiry pretext designed to drive a credential handoff, delivered without any spoofed identity.
• T1204.002 User Execution: Malicious File covers the reliance on the recipient opening the nested email attachment to reach the actual lure, since the outer message was hollow by design.

Indicators of Compromise

Detection: When the Absence Is the Signal

Static defenses had almost nothing to work with here, and that is the whole lesson. The infrastructure was reputable, the authentication was genuinely clean, and the outer message was so sparse there was little content to score. Reputation and signature checks came up empty because there was, technically, nothing wrong with how the message was sent.

Detection has to move to behavior and context. The tells were all about what the message lacked. A login-expiry warning that names no employer, no portal, no IT contact, and no system the recipient actually uses is anomalous precisely because a real internal notice would carry all of that. Pair that hollowness with a first-time sender on an unfamiliar domain that has no prior relationship with the organization, and the picture sharpens. This is where the IRONSCALES platform reads what a gateway cannot. Themis, our Adaptive AI analyst, weighs sender familiarity, the relationship graph, and the contextual emptiness of a generic credential prompt the way a trained analyst would, flagging hostile intent even when every authentication check passes. That behavioral read is what catches account-takeover attempts that ride clean authentication.

The scale of the problem is well documented. The 2024 Verizon Data Breach Investigations Report puts the human element in 68 percent of breaches and names stolen credentials as the single most common way into an environment, present in 38 percent of breaches. It also clocks the median time to click a phishing link at 21 seconds. A login-expiry notice is built to win that race, and a clean authentication verdict only helps it get in front of a reader. Across the 35,000+ security professionals across 17,000+ organizations that IRONSCALES works with, the pattern holds: an authentication pass is a starting point, not a verdict.

The Takeaway

A clean SPF, DKIM, and DMARC result tells you a server was allowed to send for a domain and that the message was not altered in flight. It does not tell you the sender is honest, and it certainly does not tell you the domain was not stood up or taken over specifically to mail you. An attacker who owns and authenticates their own domain never trips an alignment check, because there is no misalignment. The defense is to treat authentication as one input among many, to be suspicious of any account or security notice that is generic where a real one would be specific, and to inspect what hides inside attachments rather than trusting an empty body. CISA's guidance on recognizing and stopping phishing early is a solid team reference for building that reflex: https://www.cisa.gov/resources-tools/resources/phishing-guidance-stopping-attack-cycle-phase-one