The link in the email looked like it would open a document stored in a large energy company's SharePoint. Behind the SafeLinks wrapper, the real destination was an attacker-controlled subdomain with a private registration and no email-authentication records.
The message was formatted as an Invitation to Bid from an engineering consultancy. It included a professional signature block with a Phoenix address, phone numbers, and an engineering credential. The body described a project bid, listed a deadline labeled as "Important Dates," and instructed the recipient to follow the link to retrieve bid documents.
Two content anomalies pointed to a template assembled without care: the same "Important Dates" section appeared twice in the body, and the deadline listed in the body was more than a year in the past relative to the message date. Neither anomaly is obvious on a fast read of a professional-looking procurement email.
The call-to-action link, displayed as "PRP-224644_LSW Engineers Arizona - All Document," showed a URL referencing a large energy company's SharePoint tenant in the visible anchor text. The actual href, wrapped in a SafeLinks encoding, decoded to hxxps://relation123[.]ryntrao[.]com[.]de/tenders/. Automated page extraction could not confirm the content of that page, but the domain combination, an off-brand host with private WHOIS and Cloudflare fronting, is itself a strong indicator of malicious infrastructure.
A PNG attachment, Outlook-Graphical.png, was included. Its scan verdict was clean. It was not the payload vector.
The Mimecast gateway upstream of the final Microsoft 365 receiver authenticated the message successfully. ARC headers preserved those upstream assertions: SPF passed for the sending domain, and DKIM passed for the engineering firm's domain (anonymized) at the Mimecast relay. When the message transited into Microsoft 365, SafeLinks rewrote the body's URLs. That rewriting changed the signed message content, breaking the DKIM body hash. DMARC failed at the final receiver with a quarantine action. The authentication path is internally consistent: the failure at the final hop is an artifact of URL-rewriting downstream of the signing point, not evidence that the upstream authentication was invalid.
Credential harvesting attacks structured around displayed-URL spoofing depend on a specific gap in link inspection. If a security tool renders or logs the link display text but does not also extract and independently resolve the underlying href, it will score the message based on the trusted brand URL it sees in the text rather than the attacker domain in the href. The SafeLinks encoding adds another hop: a tool that resolves SafeLinks to its first unwrapped destination will see a Microsoft-served redirect rather than the attacker domain until that redirect is followed.
ryntrao[.]com[.]de resolves to Cloudflare IP addresses shared with many legitimate sites. There are no MX, SPF, or DMARC records for the domain. A private WHOIS registration provides no registrant information. None of these facts prevent the domain from appearing functional and non-blocklisted at first scan.
Our Adaptive AI identified the displayed-vs-actual URL mismatch after decoding the SafeLinks wrapper, the off-brand terminal domain, and the combined DKIM body-hash failure. The behavioral signal set was sufficient for a phishing classification independent of any page-content verdict from the attacker's server.
See Your Risk: Calculate how many threats your SEG is missing
The SafeLinks-decoded final destination, relation123[.]ryntrao[.]com[.]de, was the decisive indicator. DNS and WHOIS analysis confirmed the domain had private registration, no email-auth records, and Cloudflare fronting with no PTR records. The DKIM body-hash failure at the final receiver was traced to post-signing URL rewriting, consistent with expected SafeLinks behavior but also consistent with content modification after authentication. Combined with the repeated body sections, the past-dated deadline, and the displayed-vs-actual URL mismatch, the classification was phishing.
Decode all link-wrapping layers before scoring. SafeLinks, SendGrid tracking, and other redirect wrappers should be fully traversed before a link reputation score is assigned. A displayed URL referencing a trusted SharePoint tenant is not a clean signal if the underlying href points elsewhere. Tools that stop at the first hop will score Cloudflare IPs rather than the attacker's page. Impersonation attacks specifically exploit trusted-brand display text to manipulate first-hop scoring.
Private WHOIS combined with no email-auth records is a reliable attacker domain signal. Legitimate organizations that host document portals almost always publish SPF and DMARC records. A domain serving a "document download" page with no MX, no SPF, and no DMARC is structurally inconsistent with a real business file host. Build detection logic that treats the combination of private WHOIS, missing email-auth records, and Cloudflare fronting as a risk amplifier.
DKIM body-hash failure after gateway transit warrants investigation, not dismissal. When DKIM fails specifically on body-hash rather than signature format, the signed content changed between signing and final delivery. That can be a legitimate effect of URL rewriting, but it can also indicate attacker modification. Context matters: DKIM body-hash failure on a first-time sender with a suspicious link destination should increase the overall risk score. MITRE ATT&CK documents displayed-URL spoofing as a standard T1566 technique used widely in credential-harvesting campaigns.
Procurement and bid lures are B2B targeting. Bid invitations reach project managers, procurement officers, and engineering staff who routinely receive document links from unfamiliar vendors. The professional formatting and industry-specific content lower the recipient's defensive posture relative to generic phishing. Train staff in procurement roles to verify unexpected bid invitations through published contact information for the purported sender, not through the email's own signature block.
---
| Type | Value | Notes |
|---|---|---|
| Attacker domain | relation123[.]ryntrao[.]com[.]de | Private WHOIS; Cloudflare fronted; no SPF/DMARC/MX |
| Attacker path | hxxps://relation123[.]ryntrao[.]com[.]de/tenders/ | Revealed by decoding SafeLinks wrapper |
| Displayed URL | SharePoint tenant URL (large energy company) | Attacker used this as visible anchor text; actual href differs |
| DNS hosting | Cloudflare IPs (104[.]21[.]72[.]202, 172[.]67[.]187[.]80) | Shared CDN; origin IP hidden |
| Upstream auth | SPF pass + DKIM pass (at Mimecast gateway) | Preserved in ARC headers |
| Final-receiver auth | DKIM fail (body-hash); DMARC fail (quarantine) | Caused by SafeLinks URL rewriting post-signing |
| Attachment | Outlook-Graphical.png (43,472 bytes) | Clean scan; not the payload vector |
| Impersonated entity | Engineering consultancy sender (anonymized) | Spoofed or compromised identity |
| 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. |