The Mimecast Wrapper That Made a Phishing Link Look Safe

TL;DR A credential phishing email impersonating a Dallas law firm used a one-day-old lookalike domain, crlaws.cam, to harvest credentials from a recipient at a major financial institution. The attack's defining feature was its trust chain: every malicious REVIEW button routed through Mimecast SafeLinks rewriting, leading the recipient to believe the URL had been scanned and cleared. A fake 'Powered by Microsoft Securely' badge added a second false legitimacy signal. Upstream SPF, DKIM, and DMARC all passed at the Mimecast relay stage. The lookalike domain went NXDOMAIN before full analysis could run, a hallmark of disposable phishing infrastructure.

Severity: High Credential Harvesting Impersonation Bec MITRE: {'id': 'T1566.002', 'name': 'Phishing: Spearphishing Link'} MITRE: {'id': 'T1036', 'name': 'Masquerading'} MITRE: {'id': 'T1078', 'name': 'Valid Accounts'}

The REVIEW button looked completely normal. It had the Mimecast wrapper on it, that long url.us.m.mimecastprotect.com prefix that security-conscious employees have been trained to associate with a scanned, vetted link. The email itself was marked High Importance, the subject line was "[EXTERNAL] Settlement Release," and the legal thread below the document panel referenced real case details and real organizations.

The destination behind that REVIEW button was crlaws.cam. Registered 22 hours before the email was sent. Pointing to nothing but air by the time analysis ran.

A Domain Built for One Job

WHOIS data tells a clean story. crlaws.cam was created on November 9, 2025 at 22:42 UTC via Namecheap, with nameservers at thcservers.com. The phishing email landed in the target's inbox on November 10. By the time forensic analysis attempted to resolve the domain, it had gone NXDOMAIN. The registry status shows clientHold, which is exactly what happens when a registrar flags and suspends a domain post-abuse.

The lookalike construction is straightforward but effective. The legitimate sender domain is cr.law. The phishing domain is crlaws.cam. The visual similarity is enough to pass a casual glance, and in the context of a Mimecast-rewritten URL, most recipients are not stopping to parse the destination domain character by character.

This is throwaway infrastructure, purpose-built for a 24-hour window.

What Mimecast Rewriting Actually Does (and Doesn't Do)

This attack's central technique is not the lookalike domain. It is the deliberate routing of the malicious link through Mimecast SafeLinks.

When Mimecast scans and rewrites a URL, it produces a link that looks like hxxps://url.us.m.mimecastprotect[.]com/s/...?domain=crlaws.cam. To a recipient, that prefix signals that Mimecast has touched the URL. Employees in organizations running Mimecast see these wrappers daily on legitimate email. The wrapper becomes a trust cue.

Attackers know this.

The Mimecast rewriting does not guarantee a clean destination. It means Mimecast evaluated the URL at the time of scanning. For a domain registered one day before the email was sent, the domain may have appeared benign at scan time, resolving to nothing harmful or nothing at all. The payload activates after delivery. By the time a recipient clicks, the domain is serving the credential harvesting page. By the time analysis runs, it is NXDOMAIN.

This is a timing attack on URL reputation systems. The gap between "scanned" and "clicked" is where the damage happens.

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

The Trust Stack: Two Layers of False Legitimacy

The email body used a two-layer trust construction.

The first layer was the Mimecast SafeLinks wrapper on every REVIEW button. Both buttons in the email carried Mimecast-rewritten URLs pointing to crlaws.cam. The recipient sees a familiar security gateway prefix and reasonably concludes the link has been evaluated.

The second layer was a fake "Powered by Microsoft Securely" badge inside the document panel. That is not a real Microsoft product name. There is no Microsoft service called "Microsoft Securely." It is a visual fabrication designed to invoke Microsoft brand trust for recipients using M365 environments. Combined with a generic Security PIN displayed in the panel, it mimics the visual pattern of legitimate SharePoint or OneDrive document-sharing notifications.

Both layers target the same cognitive shortcut: this email came through my security gateway and has Microsoft branding, so it must be legitimate. Neither signal actually validates safety. Together, they lower the recipient's guard precisely enough.

Authentication Passed. That Was Part of the Problem.

The relay chain for this email adds a layer of analytical complexity that works in the attacker's favor.

The message originated from the cr.law Microsoft 365 tenant, transited Mimecast, and arrived at the recipient's M365 environment. At the Mimecast relay stage, SPF, DKIM, and DMARC all passed cleanly. The sender domain cr.law has been registered since 2017, runs SPF with include:spf.protection.outlook.com -all, publishes a p=quarantine DMARC policy, and has an active DKIM selector.

At the recipient's M365 environment, SPF showed a fail for the Mimecast relay IP (170[.]10[.]128[.]131) because that IP is not in cr.law's SPF record. DKIM body hash verification also failed, which is expected when a security gateway rewrites links in transit. ARC (Authenticated Received Chain) passed, preserving the upstream authentication result.

This is the correct behavior for a Mimecast-relayed message. The SPF and DKIM failures at the recipient hop are expected artifacts of legitimate relay rewriting. The problem is that security systems treating ARC=pass as a trust signal will smooth over those downstream failures, which is exactly the outcome the attacker is counting on.

The pattern, combined with a first-time sender flag, is consistent with a compromised account on the cr.law side or a thread-hijack overlay. The legal thread content in the email body referenced real organizations and specific case context, giving the message an authenticity that is hard to fabricate from nothing. Themis flagged behavioral anomalies in the sender profile, including the first-time sender status and the newly registered destination domain behind the Mimecast wrapper, that the gateway passed without action.

What the Gateway Passed Over

The IRONSCALES detection model treats URL rewriting from a third-party gateway as a starting point for analysis, not an endpoint. For this email, the behavioral signals were clear:

• First-time sender to the recipient mailbox, flagged high risk

• Destination domain registered the previous day, visible through URL expansion of the Mimecast wrapper

• NXDOMAIN resolution on crlaws.cam during analysis, indicating disposable infrastructure

• Fake brand impersonation in the email body ("Powered by Microsoft Securely")

• High-importance flag on an unexpected document request

No individual signal here is a slam dunk. A first-time sender from a law firm is plausible. A newly registered domain could be coincidence. But the combination, evaluated in real time against behavioral baselines across the IRONSCALES platform, produced a high-confidence phishing verdict. The email was automatically resolved as phishing without requiring manual SOC intervention.

Defending Against Trust Chain Manipulation

URL rewriting does not equal URL vetting. Every security team needs to internalize that distinction, and it needs to be a standing part of security awareness training for any organization running a gateway that rewrites links.

Specific recommendations from this case:

1. Treat gateway-wrapped URLs as unverified until analyzed. The wrapper tells you the gateway touched the URL. It does not tell you the destination is safe, especially for URLs wrapped at delivery and clicked hours later.

2. Configure post-delivery URL analysis. Static scan-at-delivery is not sufficient for fast-TTL attacker infrastructure. Time-of-click analysis, which evaluates the destination when the user actually clicks, catches domains that activate after delivery.

3. Flag first-time sender plus newly registered destination as a combined signal. Either alone is weak. Together they are a strong indicator, particularly when the destination domain is less than 48 hours old.

4. Train recipients to parse the destination domain in Mimecast URLs. The ?domain= parameter in Mimecast-wrapped links reveals the actual destination. A one-character lookalike domain (crlaws.cam vs. cr.law) is visible to anyone who looks. Most do not look.

5. Investigate authentication anomalies in relay chains. ARC=pass plus SPF fail plus DKIM body hash fail is a normal signature for legitimate gateway-relayed email. It is also a normal signature for attacker-leveraged gateway trust. Layered behavioral analysis is required to separate the two.

For financial services organizations handling inbound legal correspondence, the combination of high-importance flagging, settlement or invoice language, and embedded document review panels should trigger additional scrutiny. Attackers target exactly the workflows where speed and compliance create pressure to click first and verify later.

Indicators of Compromise

MITRE ATT&CK: T1566.002 Spearphishing Link, T1036 Masquerading, T1078 Valid Accounts

Sources: IRONSCALES platform analysis; Verizon 2024 DBIR (74% of breaches involve human element, phishing remains primary initial access vector); Microsoft Digital Defense Report 2024 (AiTM and trusted intermediary abuse increasing); FBI IC3 2024 Internet Crime Report (BEC losses exceeding $2.9 billion); CISA Phishing Guidance; MITRE ATT&CK

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 30,000+ security professionals. Each post breaks down one attack — what it looked like, why it worked, and what you can do about it.