Invisible Unicode Phishing: Verify Requests Before Sharing Secrets

Microsoft Security Research has documented a high-volume phishing campaign that inserted invisible Unicode tag characters inside finance-related words to make them harder for some email filters to parse. The message could look normal to a person while its underlying text no longer contained a continuous keyword such as "funding." Microsoft measured between one million and 2.37 million matching messages on weekdays during the campaign's intense phase.

The technique does not make every message invisible to security products. Microsoft says more than 99% of the observed messages were caught by other protection layers. The useful lesson is narrower: visible text and machine-processed text can differ, so neither a clean appearance nor a single filter decision should authorize a sensitive transfer.

What Microsoft observed

The campaign used characters from the Unicode Tags block, a mostly non-rendering range previously discussed in AI prompt-injection research. Instead of encoding a hidden instruction, the observed messages placed an invisible separator inside high-signal financial terms. Literal keyword matching or tokenization performed before normalization could then interpret the word differently from a human reader.

Microsoft's telemetry showed a sharp increase beginning February 9, 2026. The high-volume phase continued for roughly three months and fell sharply after May 15, with lower residual activity through mid-June. This is newly published research into an earlier phase of a broader campaign, not evidence that the multi-million-message peak continues today.

The lures used rotating finance-themed sender domains and legitimate email-marketing infrastructure. Microsoft connected the activity to a broader campaign previously studied by Fortra, which impersonated US small-business financing programs and collected business and financial information. Fortra's research provides independent context for the broader operation; Microsoft is the primary source for the later Unicode-tag observations.

A normal-looking request is not an authenticated request

Users often judge an email by what they can see: recognizable wording, a familiar service, a plausible business offer and a link that passes through a known marketing platform. None proves who controls the sender or where the final form sends data. Invisible characters widen the gap between appearance and evidence, but the decision problem is familiar.

Any request for a password, API key, recovery code, identity document or financial record needs a separate authorization step. Verify the person and purpose through a known phone number, internal directory, existing ticket or independently opened customer portal. Do not use contact information or links supplied only by the unexpected message to validate that same message.

Controls for mail and workflow owners

Normalize before inspection. Strip or surface unexpected non-rendering characters before applying keyword, signature and machine-learning analysis.
Keep multiple detection layers. Combine content analysis with sender, domain, URL, authentication, reputation and behavioral signals.
Test what the user and parser see. Include Unicode tags, zero-width characters and homoglyphs in controlled email-security tests.
Do not block shared infrastructure blindly. A legitimate marketing or tracking domain can carry both legitimate and abusive traffic; treat it as context rather than standalone proof.
Put sensitive requests behind an authenticated workflow. Email may notify a user, but it should not be the sole authority for choosing the recipient or destination of a secret.
Record the approval without recording the value. Keep requester, approver, purpose and expiry in the ticket while the secret travels separately.

Where one-time delivery helps

After a request is independently verified, Secretus can move a credential or recovery value through a time-limited one-time link rather than embedding it in a reply, attachment or long-lived chat. This separates the durable authorization record from the temporary secret and reduces the number of persistent plaintext copies created by the workflow.

This does not make a phishing request legitimate. It also cannot protect a value displayed on a compromised device or prevent an authorized recipient from copying it after opening. Verification must come first, followed by narrowly scoped delivery, prompt revocation and monitoring appropriate to the credential's privilege.

What is confirmed—and what is not

Microsoft confirms the technique, timing and message volumes observed in its Defender for Office 365 telemetry. The company does not publish a count of people who submitted data, accounts compromised or organizations harmed by this specific Unicode-tag variant. The Hacker News reported the research but did not provide an independent victim count or a separate forensic dataset. Those outcomes should remain unknown.