# The Invisible Ink Inside Your Inbox: How Attackers Are Hiding Phishing Words You Can't Read
Your email filter is looking for the word "funding." It won't find it — because technically, it isn't there.
Microsoft's Security Research team flagged a high-volume phishing campaign this week that's exploiting an obscure corner of the Unicode standard to slip past keyword-based email defenses. The mechanism is elegant and deeply unsettling: attackers are splitting financial lure words like "funding" with invisible Unicode tag characters — characters that render as nothing to the human eye but shatter the string that a filter is trying to match.
To your eyes, the email says "funding." To your filter, it says something else entirely.
## Unicode's Forgotten Backroom
The Unicode Tag block (U+E0000 through U+E007F) was designed decades ago for language tagging purposes and was formally deprecated. The characters are invisible — they carry no glyph, no width, no visual presence. They're still valid Unicode. Most text renderers simply ignore them.
That invisibility is the exploit.
If you insert a tag character between the "f" and the "u" in "funding," a human reader sees "funding." A regex-based email filter scanning for that exact string sees "f[U+E0066]unding" — a pattern that doesn't match. Same word, different bytestream, and your security stack never flags it.
The attackers aren't using one or two invisible characters. They're threading them throughout financial vocabulary — the exact terms that spam filters, secure email gateways, and business email compromise (BEC) detection rules specifically hunt for. Words like "wire transfer," "invoice," "payment," and "funding" are the fingerprints of financial phishing. Remove the fingerprint, keep the content, and a substantial percentage of rule-based defenses go blind.
## An AI Attack Vector Gets Repurposed
Here's what makes this campaign worth studying beyond the technical trick itself: this isn't where Unicode tag abuse started.
The security research community first documented tag character injection as a prompt injection vector against large language models. The idea was to smuggle hidden instructions into documents or web pages — instructions invisible to humans reading the text but parsed by AI models processing the underlying token stream. Researchers demonstrated attacks where an LLM would follow secret commands embedded in what appeared to be clean text.
Microsoft notes the distinction explicitly. The attackers here flipped the use case: rather than hiding instructions from people to expose them to AI models, they're hiding content from parsing systems to expose it to people. Same Unicode properties, opposite direction of deception.
That pivot is worth paying attention to. Techniques developed in AI security research are now migrating into commodity phishing infrastructure. The threat actor who built this campaign — or the tool kit they purchased — was paying attention to the academic threat modeling work. They reverse-engineered a research concept into operational evasion.
## What "High-Volume" Actually Means
Microsoft calling this "high-volume" is not incidental language. High-volume phishing campaigns require infrastructure: bulk sending accounts or compromised sending domains, automation for email construction, and templating systems that can variably place those invisible characters throughout message bodies.
This isn't a targeted spear-phishing operation against a single executive. This is a spray campaign aimed at scale — almost certainly financially motivated, using BEC-adjacent lures to drive wire transfers, credential harvesting for financial accounts, or both. The "millions of emails" framing means that even with a low conversion rate, the return on investment calculates out favorably for the attacker.
Financial sector organizations, accounting teams, and anyone in a position to authorize payments should treat this as active threat intelligence, not theoretical.
## The Filter Equation
Legacy secure email gateways — the rule-based, keyword-scanning products that many organizations still run — are structurally vulnerable to this. If your filter looks for the string "funding" and the string present in the email's raw source is "f[tag]u[tag]n[tag]d[tag]i[tag]n[tag]g," you get no match, no flag, and delivery to the inbox.
AI-powered email security tools are a more complicated case. Models trained on normalized text may or may not have seen Unicode tag injection in training data. Some will strip or normalize the invisible characters before analysis, effectively patching the bypass. Others won't. The irony is that some of the same AI email security products marketed as defenses against sophisticated attacks may be specifically vulnerable to a technique derived from AI attack research.
Defenders running email security tools should ask their vendors directly: does the product strip or normalize Unicode tag characters before content analysis? If the vendor doesn't immediately know the answer, that's your answer.
---
## HackWire Analysis
The deeper story here is about detection monoculture. Most enterprise email security is layered, but the layers frequently share the same fundamental assumption: that the text content of an email maps predictably to what a string parser sees. Unicode tag injection breaks that assumption cleanly and cheaply.
What concerns me is that this technique isn't exotic. The Unicode tag block has existed for years. Security researchers documented its abuse potential in the context of AI prompt injection — with public, detailed writeups. The gap between "researchers flag this as a theoretical attack surface" and "attackers deploy it in high-volume campaigns" closed faster than most organizations' patch cycles.
The broader pattern here connects to a trend that's been accelerating since 2023: attacker tooling is absorbing AI security research faster than defenders are. Prompt injection, adversarial inputs, and embedding manipulation were academic topics eighteen months ago. They're now appearing in commodity phishing kits.
For defenders, the immediate action is concrete: audit your email security stack's Unicode handling. Test it by sending an internal email with tag characters inserted into a keyword your rules scan for, and see if it gets flagged. If it doesn't, you have a gap. DMARC, DKIM, and SPF help with sender authentication but do nothing for content-layer evasion.
Longer term, the industry needs to stop treating ML-based email security as a solved layer. If AI security research is producing novel attack techniques faster than AI email security vendors are training against them, the marketing claims need to catch up with the technical reality.
The invisible characters are inside the perimeter. The question is whether your defenses can see what your eyes can't.
— HackWire Editorial
---
## Related Coverage