The Phishing Link Encrypted Itself: OpenSSL Salted Base64 in the URL

The subject line read "Thank you for your application." The call to action said "Review & Continue." The links looked like nothing a URL scanner had ever seen.

Every CTA in the message carried a URL parameter beginning with U2FsdGVk, the base64 encoding of the ASCII header Salted__. This is the signature of OpenSSL salted encryption. The phishing destination was not hidden behind a redirect chain or a URL shortener. It was encrypted directly into the link, making it opaque to every static analysis tool that tried to evaluate it.

Encrypted Links as an Evasion Layer

Traditional URL rewriting defenses and gateway scanners work by resolving a URL, following its redirect chain, and evaluating the landing page. When the URL path is a readable string, reputation services can match it against known-bad patterns. When the path is an encrypted blob, there is nothing to match.

The U2FsdGVk prefix identifies OpenSSL-compatible AES encryption with a passphrase-derived key. The encrypted token is only meaningful to the server that holds the decryption key. At click time, the destination server decrypts the token, extracts the real URL, and redirects the victim. Before click time, the URL is a dead end for automated analysis.

The primary links resolved through infrastructure at givingfunder[.]com, a domain registered in 2022 through Namecheap with privacy-protected WHOIS. SPF, DKIM, and DMARC all passed. The sending IP 185[.]255[.]9[.]25 resolved to mnal-ny2[.]mta[.]cloud, a commercial mail transfer agent. Webhook notification headers were present in the message, indicating the email was generated programmatically through an API rather than composed manually.

Secondary links pointed to jdkeusy[.]com, registered in 2023 with privacy-shielded registration. The domain had no public web presence and no verifiable business association. Both domains served as infrastructure for the same campaign, with the encrypted tokens routing through either endpoint depending on the recipient.

What Authentication Could Not See

The sending domain had valid DNS records, a functioning MTA, and properly configured authentication. The message was not spoofed. The infrastructure was purpose-built, registered well in advance, and maintained long enough to accumulate neutral reputation. None of these facts made the email safe.

The signal that mattered was behavioral. The sender had no prior relationship with the recipient organization. The encrypted URL structure was anomalous for any legitimate application workflow. And the combination of a first-time sender, programmatic delivery via webhook headers, and opaque link encoding created a risk profile that credential harvesting detection models are designed to catch. Themis flagged the message as high-risk and it was quarantined before any recipient interacted with the encrypted links.

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

Indicators of Compromise

MITRE ATT&CK Mapping