Your Own IT Department, Forged: BOM Encoding and a Medium Open-Redirect Hide a Vercel Credential-Harvest Portal

The email came from the recipient's own security team. At least, the display name said so: the organization's name followed by "Email Security." The subject line announced a password expiry deadline. Two buttons in the body offered the expected options: "Keep My Password" and "Modify Password." The footer carried the organization's domain. Nothing in the surface presentation suggested an external sender.

The sending address was not internal. The link destinations were not what the buttons advertised. And the path from button to landing page was engineered specifically so that the tools checking links would not see the endpoint until a real browser clicked through.

This is credential harvesting built on self-impersonation: the attacker did not borrow a brand the recipient trusts from the outside. They borrowed the recipient's own organization.

The display name was the entire trust mechanism

The sender's domain belongs to a real packaging manufacturer, registered in 2018 with standard email authentication configured. The analysis flagged the sender as an impersonation attempt: not internal to the organization, first-time contact with this mailbox, display name set to mimic the organization's own IT security function.

This is a meaningful distinction from third-party brand impersonation. When recipients see a familiar external brand in a From line, they often pause to assess whether they expected this message. When the From line shows their own IT department, the conditioned response is compliance. IT password notices arrive unannounced. They carry deadlines. You act.

The body leaned into that conditioning. A large header declared "Password Status: Expiring Today!" and the body named a specific expiry date. That date was November 21, 2025. The message was analyzed on December 2, 2025. The deadline had already passed by nearly two weeks, which is a tell that the lure was templated or reused, not dynamically generated for this recipient. The external-origin banner in the message confirmed it arrived from outside the organization, a detail that most recipients scan past when reading an urgent IT notice.

How the link hid its destination

The buttons used visible text that matched the expected action. The hrefs were something else entirely.

The actual href structure started with hxxps://youtube[.]ch%EF%BB%BF followed by extended whitespace and inter-letter spacing characters, then resolved through hxxps://www[.]medium[.]com/m/global-identity-2?redirectUrl= to the final destination: hxxps://emailserver-maintenance-portal-x4f5[.]vercel[.]app.

Breaking that down:

The %EF%BB%BF sequence is a UTF-8 byte-order mark, a non-printing invisible character that belongs at the start of a text file, not inside a URL. A link scanner parsing the href as a string may encounter the BOM, fail to normalize the URL correctly, and miss the redirect chain behind it. A browser strips the invisible bytes and resolves the real request.

The inter-letter spacing characters perform the same function at a visual layer: if a scanner or analyst prints the href to inspect it, the characters break up keyword matching and pattern recognition.

Behind both of those is the Medium.com open-redirect. Medium, a legitimate publishing platform, provides a global identity redirect path that accepts an arbitrary destination URL in the redirectUrl parameter. The attacker used this to make the first recognizable hostname in the chain a trusted domain. A tool that evaluates only the initial destination would see medium.com and pass the link.

The final landing page on Vercel arrived pre-populated with the target's email address, drawn from the portal= parameter encoded in the redirect URL: portal=accounting@[packaging-mfr-domain]. The fake portal presented as an internal email server maintenance page and solicited the password the subject line had warned was about to expire.

This is URL rewriting and link obfuscation working in combination: the attacker did not need to register a fresh malicious domain. They built the deception out of invisible characters and trusted platforms with permissive redirect behaviors.

Why scanners missed it and what caught it

A link scanner that resolves a URL by parsing the string will fail on BOM-obfuscated hrefs. The non-printing characters break string normalization, and the scanner may evaluate either the garbage prefix or the medium.com intermediate rather than the Vercel endpoint. A scanner that follows redirects fully would reach the Vercel domain, but that domain itself was generic hosting infrastructure with no prior malicious history, giving it a clean reputation score.

What does not require link resolution is behavioral context. The sending domain is external. The display name claims to be the recipient's own security team. The sender has no prior relationship with this mailbox. The expiry date in the body is two weeks stale. Any one of those signals is a weak indicator; together they form a pattern that does not fit legitimate internal IT communication, even before inspecting a single link. This technique maps to Phishing: Spearphishing Link in MITRE ATT&CK, combined with Masquerading (T1036.005) for the internal-persona display name.

Attackers deploy fake login pages on generic serverless hosting platforms because shared infrastructure makes domain-age signals unreliable. The pre-filled email address makes the portal feel like a genuine single-sign-on handoff, reducing the moment between landing and credential entry. Verizon's 2025 Data Breach Investigations Report placed credential theft as the leading phishing outcome; CISA's phishing guidance states the same defensive principle: verify a credential request through a known internal channel, not the link in the message.

Indicators of compromise

What actually caught it

The link obfuscation held up against string-based scanning. What flagged it was the combination of relationship context and behavioral anomaly: an external sender claiming to be the recipient's own security team, a deadline already expired, and CTA buttons describing internal actions that no genuine IT system would route through an external open-redirect chain. The pattern did not require resolving the Vercel endpoint. It required noticing the sender's claimed identity and actual origin did not match.

The practical lesson is narrow. When an IT notice asks for credentials, the verification should happen against the actual sending address, not the display name. The display name costs an attacker nothing to set. The actual sending domain is the field they cannot forge without breaking authentication, and here it was not the organization's own infrastructure.

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

Static link scanners check destinations against known-bad lists. This attack had no known-bad destination. The Vercel subdomain was fresh. The Medium redirect was legitimate infrastructure. The BOM prefix kept the string from resolving cleanly. Defense at this layer requires following the full redirect chain, normalizing invisible Unicode, and weighting the behavioral context around the sender regardless of what the link checks return.