# Free Hotmail, Fake Adobe: How a Relocation Lure Hid a Throwaway Credential-Harvest Domain
An attacker crafted a bare-bones moving-bid email from a free Hotmail account, attached a single link labeled "ADOBE DOCUMENT," and sent it to corporate inboxes. Every email-authentication check passed. The link scanner called it clean. The domain on the other end had never sent a single legitimate email.
The message from jeffjonesrealtor[@]hotmail[.]com carried a subject line about a moving project and a body consisting of exactly one sentence: a claim to be sharing a bid proposal. The only call to action was a button labeled ADOBE DOCUMENT. There were no invoice numbers, no project references, no personalization, and one misspelling in the sign-off ("Best Reagrds").
Microsoft SafeLinks rewrapped the destination URL at delivery. The final resolved address was hxxps://omay[.]life/adobe_document/. The domain omay[.]life has no MX records, no TXT records, and no _dmarc record. Its only DNS presence is a pair of Cloudflare A records (104[.]21[.]83[.]180 / 172[.]67[.]180[.]123), consistent with a throwaway landing page hosted behind Cloudflare's reverse proxy to obscure origin.
The attacker's choice of a Hotmail account was deliberate. SPF, DKIM, and DMARC all passed because the message legitimately originated from Microsoft's own outbound infrastructure. Those three checks answer one question: did this message come from an authorized mail server for this domain? A genuine Hotmail account answers "yes" to all three.
Phishing that uses free consumer webmail exploits this gap intentionally. The receiving mail stack had no basis to fail authentication, so the message entered the delivery pipeline with a clean auth posture. The SCL=5 quarantine assignment came from behavioral heuristics, not from any failure in the authentication chain.
SafeLinks scanned omay[.]life and returned a clean verdict. Throwaway domains benefit from a grace period on reputation-based scanning: a domain registered specifically for a campaign has no prior abuse history. URL reputation systems score against the past; a brand-new domain starts at zero.
See Your Risk: Calculate how many threats your SEG is missing
The concrete attacker artifact here is the mismatch between the visible link label and the actual destination. A link displayed as "ADOBE DOCUMENT" should resolve to an adobe.com domain. It resolved to omay[.]life. That discrepancy is a class of signal that social engineering detection focuses on explicitly: the visual trust cue (a recognizable brand name) does not match the technical destination.
Themis (our Adaptive AI) correlated the brand-label mismatch against the domain's absence of any supporting email-authentication infrastructure and its Cloudflare-only DNS posture. Combined with the first-time external sender flag and the high sender-risk score, those signals produced a phishing classification independent of the clean link-scanner verdict.
The message was quarantined at SCL=5 before delivery to both affected mailboxes. No credential submission is confirmed.
SafeLinks and similar URL-rewriting proxies perform reputation lookups at click time, which is better than nothing but insufficient against fresh domains. Organizations relying solely on URL reputation for link-borne phishing will miss campaigns built around newly registered throwaway infrastructure.
Three controls add meaningful coverage here:
hotmail.com, gmail.com) sending inbound business documents warrant elevated suspicion, especially on first contact._dmarc record is not a business domain. Treat it accordingly.Relocation and bid proposals are seasonally common pretexts. Defenders should brief end users that document-share requests from unknown webmail accounts require out-of-band verification before any link is clicked.
See the MITRE ATT&CK technique reference at https://attack.mitre.org/techniques/T1566/ and https://attack.mitre.org/techniques/T1598/.
| Type | Value | Notes |
|---|---|---|
| Sender address | jeffjonesrealtor[@]hotmail[.]com | Attacker-controlled free webmail |
| Malicious domain | omay[.]life | No MX/TXT/_dmarc; Cloudflare-only DNS |
| Malicious URL | hxxps://omay[.]life/adobe_document/ | Credential-harvest landing |
| IP | 104[.]21[.]83[.]180 | Cloudflare proxy for omay.life |
| IP | 172[.]67[.]180[.]123 | Cloudflare proxy for omay.life |
| Pretext | Moving/relocation bid proposal | Generic one-line body |
| Authentication result | SPF/DKIM/DMARC: pass | Hotmail infra; auth does not validate content |
| Attack | What happened |
|---|---|
| The Email That Passed Every Security Check (Because Adobe Sent It) | A phishing campaign targeting school district staff used Adobe's own sending infrastructure, real DKIM signatures. |
| The Phishing Infrastructure Was Canva. The Delivery Mechanism Was Canva. The Authentication Was Canva. | An attacker signed up for Canva, built a phishing lure as a design, and used the platform's own sharing feature to deliver it. |
| When the Sender Domain Is Also the Phishing Kit Host: Dual-Purpose Domain Compromise | An attacker compromised a legitimate manufacturing company domain and used it two ways at once: as the authenticated sending address and as the host for... |
| The Subdomain That Fused Two Trusted Brands Into One Convincing Lie | Attackers fused two real brand names into a single subdomain, routed the message through Zix infrastructure to inherit enterprise authentication. |
| The SendGrid Email That Came From a Window Company | A pixel-perfect SendGrid notification arrived from a compromised window manufacturer's domain. |