3scsolution[.]com (DKIM pass, SPF softfail from origin IP 185[.]121[.]176[.]34) used a legitimate open-redirect endpoint on richelieu[.]com to route victims to the attacker-controlled domain madaalfadhaa[.]com/.xiaz. The redirect URL embedded the recipient's email address as a Base64-encoded tracking parameter. Genuine msc[.]com links appeared in the message body as trust decoys. The lure claimed a contract document was available, expiring in 24 hours.# MSC Brand Impersonation Abuses a Legitimate Open Redirector and Base64-Encodes the Victim's Address for Targeted Tracking
A phishing campaign targeting a property-management firm took a straightforward lure concept (fake shipping document from a well-known carrier) and layered on two evasion techniques that are individually common but rarely combined this cleanly: abusing a legitimate website's open redirector to mask the real destination, and encoding the victim's email address into the redirect URL so the landing page could target them specifically. The result was an email whose primary CTA pointed to a trusted retail domain and whose attacker-controlled destination had essentially no public footprint to scan against.
The message displayed Mediterranean Shipping Company (MSC) branding throughout, including corporate legal text referencing msc[.]com and a document lure with a filename following the pattern Contract_Agreement_[recipient].pdf. The subject line and body tone matched the template language MSC-branded phishing campaigns have used in prior waves.
The actual sending domain was 3scsolution[.]com, which has no affiliation with MSC. DKIM passed for 3scsolution[.]com, so the message carried a valid cryptographic signature, just not one tied to the claimed brand. The originating IP was 185[.]121[.]176[.]34, which produced an SPF softfail (the domain's SPF record discourages but does not hard-fail that IP). The IP has no PTR record and no recognized gateway affiliation, placing it in the category of untrusted origin infrastructure. The mismatch between the DKIM-authenticated sending domain and the MSC brand displayed in the body is the canonical fingerprint of brand impersonation: authentication passes for one entity while the recipient is led to believe they are hearing from another.
The primary CTA, "REVIEW THE DOCUMENTS," linked to a URL on richelieu[.]com using that site's newsflash/redirect.php endpoint, a redirect mechanism on a legitimate, established retail site. The redirect's destination parameter pointed to madaalfadhaa[.]com/.xiaz.
richelieu[.]com is not an attacker domain. It is a legitimate business operating a redirect endpoint that accepts external URL parameters without restriction, a classic open redirector. Attackers target open redirectors specifically because the domain visible in the email link is reputable and passes URL reputation checks that would flag an unknown domain as suspicious. The scanner sees richelieu[.]com and may not follow the redirect to evaluate the terminal destination.
The attacker-controlled landing at madaalfadhaa[.]com has no established reputation and no indexable presence, a domain created for this campaign with no prior footprint that threat feeds could act on at delivery time.
See Your Risk: Calculate how many threats your SEG is missing
Embedded in the redirect URL was a parameter containing the recipient's email address encoded as a Base64 string. This encoding technique serves two functions. On the landing page, it allows the credential-harvesting form to pre-populate the victim's address, creating the illusion that the portal already has an account on file. For the attacker, it confirms that the specific address received and engaged with the email, a validation mechanism for refining target lists.
This is not a bulk-spray campaign that happened to reach a property-management firm. The per-address encoding is evidence of deliberate targeting: each recipient received a unique URL confirming their address to the attacker's infrastructure on click. That level of targeting changes the risk profile. Even if a recipient does not submit credentials, clicking the link alone signals to the attacker that the address is active and the target is reachable. Once the landing page collects a username and password, the attacker has everything needed for credential harvesting follow-on access and downstream fraud.
The message body included two links to genuine msc[.]com content, including a real MSC data-protection PDF. Including clean, verifiable links from the impersonated brand is a deliberate technique to dilute automated scanning results and to reinforce the impression that the message originates from MSC's actual infrastructure. The body also stated the document link would expire in 24 hours, a standard urgency mechanism designed to override the recipient's instinct to verify before clicking.
Themis identified the sending domain mismatch against the claimed brand, the suspicious origin IP, and the redirect chain terminating at an unknown domain with no reputation. The encoded recipient parameter and the open-redirect pattern are recognizable structural fingerprints that behavioral analysis can act on even when the initial URL scans clean.
URL reputation checks that do not follow redirect chains provide no protection against open-redirector abuse. Defense against this technique requires full redirect chain traversal to the terminal URL, combined with inspection of URL parameters for encoded recipient data. Legitimate shipping carriers do not embed customer email addresses as Base64 parameters in document links.
| Type | Indicator | Notes |
|---|---|---|
| Domain | 3scsolution[.]com | Sending domain (DKIM-authenticated, not affiliated with MSC) |
| IP | 185[.]121[.]176[.]34 | Origin sending IP; no PTR; SPF softfail |
| Domain | madaalfadhaa[.]com | Attacker-controlled landing page |
| URL | hxxps://madaalfadhaa[.]com/.xiaz | Credential-harvesting endpoint |
| Redirector | richelieu[.]com/newsflash/redirect[.]php | Legitimate site abused as open redirector |
| Technique | Base64-encoded recipient tracking | Recipient address embedded in redirect URL parameter |
| Attack | What happened |
|---|---|
| The Button Text Was the Weapon: Unicode RTL Obfuscation Inside a DocuSign Lure | Attackers embedded Unicode right-to-left marks directly inside a CTA button label to scatter the string for NLP scanners. |
| The DocuSign Lure That Used Google as a Trust Shield (And Encoded Your Email in the Link) | A DocuSign phishing email hid its harvest domain behind a google.com redirect and encoded the recipient's exact email address into the link as base64. |
| The B2B Content Marketing Email That Borrowed a Brand, a Relay Allow-List, and a Security Vendor's Own URL Wrapper | A polished B2B research report offer used SelectHub branding, passed through an allow-listed mail relay at SCL -1. |
| 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. |