When a University's Own Domain Blasts a Job Scam

The message that landed in a regional health system's nursing-education program did not come from a throwaway domain, a spoofed header, or a suspicious relay in some far-off data center. It came from a real Mexican vocational-education institution's own Microsoft 365 tenant. Every gateway signal a legacy filter leans on told the same reassuring story: this is authenticated mail from a genuine sender. The problem was that the genuine sender had been turned into a delivery machine for a Federal Work-Study job scam, and it was blasting the same lure to hundreds of academic and personal addresses at once.

The recipients on this side of the incident were a handful of mailboxes tied to a nursing-education program. Four were confirmed hit. But the send list was enormous and indiscriminate, a scattershot of unrelated .edu and personal inboxes that had no business relationship with the sending school. That indiscriminate breadth is the whole story here, because it is the one thing the authentication stack could not see.

Real infrastructure, honest signatures

Start with what passed. SPF returned a clean pass: the envelope sender aligned to the school's domain and the message left through Microsoft's Exchange Online Protection infrastructure for that tenant, from a genuine Microsoft sending address. DKIM passed as well, signed by the tenant's own onmicrosoft[.]com signing domain (conalepmexedu.onmicrosoft[.]com), with the ARC chain intact through the hops. Composite authentication landed on compauth=pass with reason=109.

None of that is a bypass or a forged check. When a legitimate account inside a tenant is compromised or abused, mail sent from it is authenticated honestly, because it really is coming from the authorized infrastructure. SPF confirms the sending server is allowed to send for the domain. DKIM confirms the domain signed the message. Neither one has any opinion about whether the human behind the account is doing something malicious. The 2024 Verizon Data Breach Investigations Report puts stolen credentials at the top of initial breach actions, involved in 38% of breaches, and this case is a clean illustration of why: once an attacker owns a valid account, the entire authentication layer works in their favor.

The one control that could have added signal was simply absent. The sending domain published no DMARC record at all. A lookup for the _dmarc subdomain returned nothing, so the message was scored as a best-guess pass with no policy behind it. DMARC would not have blocked mail sent from the tenant's own authenticated servers, since alignment held for the abused domain itself, but its total absence meant there was no enforcement posture and no aggregate reporting to surface the sudden spike in outbound volume. The domain had no way of knowing it was being used as a weapon, and no policy asking anyone to care.

The lure and the payload

The email carried a legacy .doc attachment named as a combined staff-and-student employment form, weighing in at just under 19 kilobytes. The platform verdict came back clean; the sandbox could not independently detonate it. That "clean" verdict deserves an asterisk. A legacy .doc file is macro-capable by format, and pairing it with an employment-onboarding pretext is a textbook job-scam pattern. The play is to move the sensitive data capture out of the email body, where it would look obviously fraudulent, and into a document the target is expected to open and complete. Social Security numbers, dates of birth, and bank-account details for "direct deposit" get harvested inside the form rather than typed into a suspicious web page.

Work-Study framing is what makes this land. Campus employment is routine, expected, and financially motivated. A student or a staff member managing a nursing-education program is not primed to be suspicious of an employment form; they are primed to fill it out. The attacker is not fighting the recipient's skepticism, they are riding the recipient's normal workflow. This aligns with MITRE ATT&CK's T1566/001 spearphishing attachment technique, delivered through an abused account that maps to T1586/002, compromise of email accounts.

There was one more crack in the disguise, visible only if you looked past the authentication result. The sending account's own metadata and the header language were Spanish, consistent with a Mexican vocational school, while the lure body pitched a U.S. federal-program job in English. A domain built for one country's student population does not, in the normal course of business, mass-mail a United States Work-Study offer to strangers. That subject-and-attachment mismatch, layered on top of the volume anomaly, is the fingerprint of abuse.

Why volume, not authentication, was the tell

Because every technical check passed, the detection had to come from somewhere else. It came from behavior. A first-time-sender academic domain suddenly blasting hundreds of unrelated recipients, with a theme that did not match the sender's own profile, is a campaign-pattern anomaly. IRONSCALES Adaptive AI evaluates that pattern the way a suspicious human analyst would, weighing send volume, sender familiarity, recipient graph, and content-theme consistency together rather than trusting a green authentication badge in isolation. Themis flagged the send on those signals, and a SOC analyst confirmed it. A program coordinator on the recipient side had also reported it, and the mailboxes were remediated across the affected group.

The uncomfortable lesson for defenders is that "authenticated" and "safe" are not the same word. The 2024 DBIR notes the human element is a component of 68% of breaches, and abused legitimate accounts are one of the cleanest ways to weaponize that human trust. When mail genuinely originates from a real tenant, SPF and DKIM will vouch for it honestly, and a missing DMARC record removes even the thin possibility of policy friction. What is left is the shape of the campaign: who is sending, to how many strangers, saying what, all at once. Guidance from CISA on stopping the phishing attack cycle points in the same direction, treating detection as a layered behavioral problem rather than a single gate.

For any organization, the takeaway is to stop treating a clean authentication result as the end of the inquiry. Compromised-account abuse of this kind is exactly why account-takeover protection and behavioral analysis have to sit downstream of the gateway, not be replaced by it. It is also why phishing simulation and training matter for the last mile, since a Work-Study employment form only pays off if a recipient opens it and fills it in.

Indicators of Compromise

• Sending account: blucero3120[at]conalepmex[.]edu[.]mx (abused/compromised tenant account, not the actor's real identity)
• Sending domain: conalepmex[.]edu[.]mx (Microsoft 365 tenant, GoDaddy nameservers)
• Mail exchanger: conalepmex-edu-mx.mail.protection.outlook[.]com
• Sending domain A record: 192.124.249[.]15
• DKIM signing domain: conalepmexedu.onmicrosoft[.]com
• Attachment: legacy .doc staff-and-student employment form, ~18.9 KB, macro-capable, verdict clean
• Authentication: SPF pass, DKIM pass, DMARC none (no _dmarc record published), compauth=pass reason=109

MITRE ATT&CK Mapping

• T1586/002 (Compromise Accounts: Email Accounts). The abused Microsoft 365 tenant supplied authenticated delivery.
• T1566/001 (Phishing: Spearphishing Attachment). The macro-capable employment form was the PII-harvesting payload.