Text Salting: Why Hidden-Text Phishing Grew 9x in Six Months

Research by Yuval Tzadok and Ofek Ohana, IRONSCALES Research

Text salting is the practice of hiding a large block of harmless text inside a phishing email so the AI model scoring it reads a mostly benign document while the human sees only the lure. The technique is old. What’s new is that it stopped being a trick individual attackers pull and became something a toolchain emits. Over six months we watched its share of evasive phishing grow nine-fold, always paired with the same second evasion, always using the same class of hiding technique. That pattern is the story. Here is what we found, why it works, and what it takes to catch it.

Open the email and it looks short. A greeting, a lure about a reward or an account that needs attention, a link. Maybe forty words. Nothing about it reads as unusual.

Open the HTML source and the email is nine hundred words long.

The other 860 words are a block of harmless prose. A fake newsletter. An invented chat thread between two coworkers. A paragraph that reads like it was lifted from an encyclopedia. The block is wrapped in CSS that makes it disappear completely. display:none. opacity:0. font-size:0. Or positioned thousands of pixels off-screen. These are hard hides. The text does not render in any client, in light mode or dark, and no amount of squinting or select-all will surface it.

The recipient never sees it. The AI classifier reads all of it. The industry has a name for the trick, text salting, and it has been around in cruder forms for years. What’s changed is who it’s aimed at, and who is doing it.

Why this works

Most email security products now score message text with some kind of language model, whether that’s a classic NLP classifier or, increasingly, an LLM. The pattern is the same either way. You hand the model the message, it reads the whole thing, it returns a threat score. That approach has a blind spot, and it has nothing to do with how well the model understands phishing. The model reads the raw content of the email. A human reads the rendered email. Those are two different documents.

The attack lives in that gap. The phishing payload (the lure, the link) sits in normal, visible text. The attacker then appends a large block of ordinary-sounding filler and hides it. To the model, the message is now a short suspicious paragraph followed by hundreds of words of benign narrative. The volume of “normal” content drags the overall score down, below the line where the email gets flagged.

Nobody fooled the model about what phishing looks like. They watered it down with content no human will ever read.

The numbers, and the direction they’re moving

Our research team (credit to Yuval Tzadok and Ofek Ohana) went back through six months of confirmed phishing built to evade automated filters, the hard cases that took a user report or an analyst’s eye to close out. Roughly 7% of them carried this hidden-text block.

The trend matters more than the share. In December 2025 the technique showed up in about 1% of those cases. By June 2026 it was 11%. That’s a nine-fold increase in half a year, and the growth is entirely attacker-driven. The false-positive rate on the pattern stayed flat and near zero the entire time, which tells you legitimate senders did not start doing this. Attackers did.

One more figure worth knowing, and it turns out to be the important one. In 84% of the cases, the hidden text traveled with a second trick.

The second trick: a link that shows scanners a decoy

The visible link in these emails points to a throwaway domain the attacker controls. That URL is a cloaking redirector. It checks who is fetching it and returns a different destination depending on the answer. A real person clicking from a real inbox lands on the malicious page. An automated scanner following the link gets bounced to a harmless decoy, in this campaign news.google.com.

So the scanner sees an email that resolves to Google News and a body that reads mostly like a newsletter. Two independent signals, both saying “benign,” both manufactured.

The destination for actual victims rotates across affiliate-fraud hosts (fake reward funnels, survey and subscription traps) and credential-harvesting login pages built to impersonate familiar brands. The domains change constantly. The URL structure behind them does not. We know any of this because our analysis follows redirects the way a real client does, which is how Google News turned up in the first place. The cloaking is context on the campaign. The detection signal is the hidden text.

One kit, not many hands

Two things about this campaign don’t fit the picture of individual attackers copying a trick from a forum. The second trick above is the first of them.

The first is the pairing. Hidden-text dilution and link cloaking are unrelated evasions. One targets the content model, the other targets the URL scanner, and they require different skills to build. Attackers who learn one have no particular reason to learn the other. Yet in 84% of these emails they arrive together. Two independent evasions co-occurring at that rate is a signature of one toolchain emitting both, the way a phishing kit bundles a landing page, a credential form, and an exfiltration script. Nobody assembled these emails by hand.

The second is the discipline. Across six months and thousands of samples, the hidden block always uses hard hides. display:none, opacity:0, font-size:0, off-screen positioning. Never the soft kind, like near-white text or a two-pixel font, which a person copying a tutorial would reach for first and which some clients render anyway. A human operator would get this wrong sometimes. The kit never does, which is also why our false-positive rate stayed flat. Legitimate mail is full of soft hides and empty of hard ones, so a detector keyed on hard hides never confuses the two.

Put those together and the growth curve reads differently. A technique spreading by word of mouth climbs slowly and unevenly. A kit going into circulation climbs the way this did, from about 1% of evasive phishing to 11% in six months, with the filler and the hides staying consistent the whole way. We’re describing behavior, not authorship. We can’t see the kit and we can’t prove what wrote the filler. But the filler is consistent, it is always positioned where a scoring model reads it and a human doesn’t, and it arrives alongside a second evasion built for a second scanner. That’s industrial production.

The tell is structural

Legitimate email hides text all the time. The grey preview line your inbox shows before you open a message is hidden text. Dark-mode duplicate copies are hidden text. Threading tokens, tracking beacons, and the CSS that makes a footer collapse on mobile are all hidden text. Flag “hidden text” as malicious and you will drown.

The shape of what’s hidden is what makes this campaign detectable. Legitimate hidden text is short, or it duplicates something already visible. The attack’s hidden text is bulky (a hundred words or more), it contains no links, it appears nowhere in the visible message, it sits right next to the real content, and it uses at least one hard-hiding technique that renders it invisible in every client, light mode or dark. That combination almost never occurs in normal mail.

The attacker can write any filler and copy any hiding technique from a CSS tutorial. They can’t escape the structure. A large block of concealed text that is foreign to what the recipient sees is the durable signal, and it’s the one our detector keys on.

Why a CISO should care about a fake reward email

Two reasons.

First, these are live malicious emails. Every one carries a working link into fraud infrastructure. People who click get scammed, get their credentials harvested, or both. That harm is happening now, at a rate that grew nine-fold in six months.

Second, the evasion is the real threat. These actors have a reliable, repeatable method for pushing arbitrary content past an AI email filter. Today the payload is a fake reward. The same wrapper, unchanged, carries a credential-harvesting page or a malware dropper tomorrow. You are looking at a working bypass, and the bypass will carry whatever comes next.

This is not one vendor’s problem

Any classifier that ingests the full text of an email has this exposure. That’s why we’re publishing the mechanics instead of treating it as one vendor’s bug to patch quietly.

The larger point is about what the adversary has become. Phishing 1.0 was bad content, and gateways learned to scan it. Phishing 2.0 was bad intent, and behavioral models learned to read it. This campaign is Phishing 3.0 in practice. The attacker is producing email at industrial scale with a toolchain that already knows what the scoring model rewards and manufactures it, on purpose, in a channel the human never sees. A defense that consists of a model reading the whole message is now facing an opponent that iterates against models. The model alone will lose that race. The defense has to be structural.

Know what the human sees. The raw HTML is the wrong document to grade on its own. If a classifier scores content that no recipient can perceive, that invisible content is attack surface. The fix is a view of the email that separates what renders from what’s concealed. Our research team built exactly that. A dedicated CSS-evasion detector, a separate model that fires when an email carries a bulky block of hard-hidden text that appears nowhere in the visible body. The language model still reads the whole message. The detector makes sure the hidden nine hundred words count against the email instead of for it.

Detect the shape. Filler text and CSS tricks are infinitely variable, and a kit can regenerate both faster than any signature updates. The structure of the attack (bulky, hidden, foreign to the visible body) stays constant, because it’s the structure that makes the dilution work. Detectors built on that structure hold up when the next kit version swaps the newsletter for a chat log and display:none for font-size:0.

What to do with this

If you run email security, ask your vendor one question. Does anything in the pipeline distinguish what the recipient sees from what the HTML contains? A vendor who can’t answer that cleanly has this gap.

Attackers have started writing emails for the machine instead of the person. The fix is to make the machine read like a person.

Frequently asked questions

What is text salting in email? Text salting is hiding extra text inside an email’s HTML that the recipient never sees. Attackers use it to change how an automated filter reads the message. In the campaign described here, the hidden text is a large block of harmless prose that dilutes the AI classifier’s threat score so a short phishing lure passes as benign.

Does text salting work against every AI email filter? Any filter that scores the raw HTML text of an email, whether a classic NLP classifier or an LLM, is exposed, because it reads content the recipient cannot see. The defense is a separate check that distinguishes rendered text from concealed text and treats a large, foreign, hard-hidden block as a signal.

Why not just strip hidden text before scoring? Legitimate email hides text constantly. Preview lines, dark-mode duplicates, threading tokens, mobile layout CSS. Stripping all of it degrades the model’s read of normal mail. Flagging all of it drowns the SOC. The detectable difference is structural. Attack text is bulky, contains no links, appears nowhere in the visible body, and uses hard hides that no client renders.

Is this the same as prompt injection? No. Prompt injection hides instructions for an AI assistant, like the 2025 attack on Gmail’s Gemini summaries. Text salting hides filler to water down a classifier’s score. One manipulates what an AI does; the other manipulates what an AI concludes.

How is text salting different from the CSS abuse Cisco Talos described in 2025? Same family. Talos documented CSS-hidden text used to defeat keyword, brand, and language detection. The 2026 wave points the same mechanics at the language models that score intent, pairs it with a cloaking redirect, and arrives at a scale and consistency that indicates a toolchain rather than individual operators.

Research: Yuval Tzadok and Ofek Ohana, IRONSCALES Research. Yuval identified the campaign, built the detector, and wrote the first draft of this analysis. Ofek led the research program.