> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # Phishing emails are baiting your AI assistant - URL: https://f4n6.co.uk/security-feed/phishing-emails-are-baiting-your-ai-assistant/ - Published: 2026-10-12T12:16:16.000Z - Updated: 2026-10-12T12:16:16.000Z - Author: Jeff Davies - Tags: #security-feed ## 1\. Executive summary Attackers are embedding hidden instructions in phishing emails so that AI assistants which summarise or triage a mailbox surface the attacker's request as the assistant's own recommendation. Barracuda research, reported by Malwarebytes, describes emails built for two audiences at once: a password-protected attachment and the password for the human recipient, and concealed prompt-injection text for any AI system that ingests the raw message. One documented example instructs a summarising assistant to add a fake priority action to change a vendor's payment details, which points directly at invoice and payment-diversion fraud in financial services. No CVE, no CISA KEV entry and no named threat actor are associated with this item; the risk is a technique class, not a tracked vulnerability. The exposure is concentrated in firms that have enabled mailbox-summarisation assistants with write or action permissions before stripping hidden content from inbound mail. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | DORA Art. 17 | The technique targets the ICT-supported process by which staff triage and act on inbound email, and the documented payload is a payment-detail change instruction | Firms need an incident-management process that covers AI-assistant-mediated fraud attempts, not only conventional malware incidents | | NIS2 Art. 21(2)(d) | The attack path runs through an AI email assistant, which is a supplier-provided component inside the mail-processing chain | Supply chain security measures must extend to the AI assistant vendor's handling of hidden content and its permission model | | DORA Art. 28 | The assistant is typically a third-party service with access to mailbox content | Third-party risk assessment must cover the assistant's data access and its safeguards against injected instructions | No other article in the reference is directly engaged. The item contains no confirmed incident at a named entity, so DORA Art. 19 and NIS2 Art. 23 reporting triggers are not established by the source material. ## 3\. Technical analysis & attack chain The source describes a technique class rather than a single campaign. The confirmed steps, as reported by Barracuda via Malwarebytes, are: 1. The attacker sends an email that carries two payloads. For the human recipient, a password-protected attachment with the password supplied in the email body. For any AI system that processes the message, hidden instructions. 2. The hidden instructions are concealed using one or more of: comments in the email's underlying HTML, text made invisible through styling, encoded content, and invisible zero-width characters. These render as nothing to a person reading the message but remain present in the raw content. 3. When an AI assistant summarises or triages the mailbox, it ingests the raw message. Whether the hidden text reaches the model depends on how that specific tool extracts and prepares the email. 4. If the instructions reach the model, the assistant may describe the email as legitimate or urgent, or insert a fabricated priority action. The documented example instructs the assistant to add "Change a vendor's payment details" as a recommended action. 5. The employee acts on the assistant's recommendation rather than the original message, and payment is redirected to an attacker-controlled account. The mechanism is indirect prompt injection: instructions arrive inside material the model is meant to read, and the model has no reliable way to distinguish text it should read from instructions it should follow. The source quotes Apollo Raines, developer of the AI code review service ShipItClean, making that point directly. The consequence for defenders is that the human's decision not to open the attachment or click the link does not remove the risk, because the assistant processes the message regardless. Concealment techniques named in the source are HTML comments, CSS-based invisibility, encoded content, and zero-width characters. Related reporting adds two adjacent techniques that use the same human-versus-machine gap. Microsoft Threat Intelligence observed a high-volume phishing campaign using invisible Unicode tag characters (U+E0000 to U+E007F), the range popularised in prompt-injection research as ASCII Smuggling, to split financial lure words such as "funding" so that email filters could not parse them; hits on Microsoft's hunting signature rose sharply from 9 February 2026 and stayed elevated on weekdays for roughly three months. Barracuda separately reported more than one million retail-themed phishing attacks since April using text salting, where benign-looking filler words are hidden from the human reader using CSS cropping, off-screen positioning, or zero-font techniques, and are intended to push an AI or LLM-based filter toward a benign classification. Two caveats apply. The Barracuda research is reported second-hand through Malwarebytes and Dark Reading; the underlying report was not reviewed for this advisory. The Microsoft ASCII-smuggling campaign and the Barracuda text-salting campaign are separate operations from the prompt-injection examples in the primary item, and the sources do not establish that the same actor is behind them. Treat the linkage as a shared technique family, not a shared attribution. No malware family, C2 infrastructure, persistence mechanism, privilege escalation path, or exfiltration channel is described in the source material. The impact described is fraudulent payment redirection and, where the assistant holds broader permissions, unauthorised actions or disclosure of sensitive information. The source does not confirm that any of these outcomes occurred at a named victim. ## 4\. Mitigation & containment P1, within 24 hours - Inventory every AI assistant with read access to mailboxes, and for each one record whether it can also create tasks, send mail, or modify records. Any assistant with write or action permissions on payment-related workflows should have those permissions removed until its handling of hidden content is verified. - Require human verification of the original message, not the assistant's summary, for any recommendation involving money, payment details, or sensitive data. This is the control the source names explicitly, and it is the only one that holds if the assistant is successfully manipulated. - Configure mail flow to strip or quarantine messages containing characters from the Unicode Tags block (U+E0000 to U+E007F) before they reach any assistant. Exclude the England, Scotland, and Wales subdivision flag emojis, which are legitimately encoded with tag characters and caused false positives in Microsoft's first signature. - Where the assistant vendor exposes a setting to disable hidden-content ingestion or to render mail to visible text before summarisation, enable it. P2, within 72 hours - Test your mail security stack against the concealment techniques named in the source: HTML comments, CSS-hidden text, encoded content, zero-width characters, and text salting via CSS cropping, off-screen positioning, and zero-font styling. Confirm whether your gateway compares user-visible content against raw content and alerts on divergence. - Add sender reputation, authentication results, embedded URL inspection, and HTML-rendering checks to the filtering path. Barracuda's recommendation, as reported, is a layered approach rather than reliance on keyword detection alone. - Review whether your AI spam filter is making classification decisions on raw text. If it is, and it cannot be configured to ignore hidden content, consider removing it from the decision path. P3, within 7 days - Add a payment-detail change control that requires out-of-band verification with the vendor through a previously known contact, independent of any email or assistant output. - Log assistant-generated recommendations that touch payment or account data, and review them retrospectively for injected actions. - Reassess the assistant vendor under your third-party risk process against DORA Art. 28, covering how the vendor extracts message content and what it does with hidden text. ## 5\. Indicators of compromise No atomic indicators of compromise are present in the source material. The sources describe behaviours and concealment techniques rather than file hashes, domains, IP addresses, or URLs. ### Behavioural indicators | Behaviour | Where to observe | Confidence | | -------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------- | | Inbound email containing characters in the Unicode Tags block (U+E0000 to U+E007F), excluding subdivision flag emojis | Mail gateway content inspection, raw message source | High, corroborated by Microsoft Threat Intelligence telemetry | | Divergence between user-visible email content and raw HTML content (hidden comments, CSS-hidden text, encoded blocks, zero-width characters) | Mail gateway HTML rendering comparison | High, named by Barracuda via Malwarebytes | | AI assistant summary containing an action item that does not appear in the visible body of the source email | Assistant audit logs, task-creation logs | Medium, described as a risk in the source, not confirmed in production telemetry | | Password-protected attachment with the password supplied in the same email body | Mail gateway attachment inspection | High, described in the Barracuda example | | High volume of benign-looking filler words in an email that are not visible to the recipient | Mail gateway raw-versus-rendered comparison | High for the text-salting campaign, single-sourced to Barracuda | ## 6\. Detection The sources give usable artefacts for a Sigma rule: the Unicode Tags block range and the visible-versus-raw content divergence. No file-level artefacts, command lines, or filenames are present, so no YARA rule is emitted. ```yaml title: Inbound Email Containing Unicode Tags Block Characters id: 7f3c1a92-4b8e-4d21-9c6a-2e5f8a1b0d47 status: experimental description: Detects inbound email carrying characters from the Unicode Tags block (U+E0000-U+E007F), the range abused for ASCII smuggling and prompt injection against AI mail assistants. Excludes the England, Scotland and Wales subdivision flag emojis, which are legitimately encoded with tag characters. author: Adverse Trace date: 2026-10-12 references: - https://www.malwarebytes.com/blog/ai/2026/10/phishing-emails-are-baiting-your-ai-assistant - https://www.microsoft.com/en-us/security/blog/2026/09/03/ascii-smuggling-crosses-over-from-ai-prompt-injection-to-phishing-evasion/ logsource: category: email_gateway product: generic detection: selection_tags_block: raw_message|re: '[\x{E0000}-\x{E007F}]' filter_subdivision_flags: raw_message|contains: - "\U0001F3F4\U000E0067\U000E0062\U000E0065\U000E006E\U000E0067\U000E007F" - "\U0001F3F4\U000E0067\U000E0062\U000E0073\U000E0063\U000E0074\U000E007F" - "\U0001F3F4\U000E0067\U000E0062\U000E0077\U000E006C\U000E0073\U000E007F" condition: selection_tags_block and not filter_subdivision_flags falsepositives: - Legitimate messages forwarded by security researchers testing tag-character behaviour - Email security gateways and mailbox providers that insert tag characters as artefacts level: medium ``` ```yaml title: Email Visible Content Diverges From Raw HTML id: 2a8d5e14-6c37-4f90-b1d2-9a4e7c3f5b08 status: experimental description: Detects inbound email where the rendered, user-visible text differs materially from the raw HTML source, indicating hidden content such as HTML comments, CSS-hidden text, encoded blocks or zero-width characters used to carry prompt-injection instructions past a human reader. author: Adverse Trace date: 2026-10-12 references: - https://www.malwarebytes.com/blog/ai/2026/10/phishing-emails-are-baiting-your-ai-assistant - https://www.theregister.com/security/2026/07/17/ai-spam-filters-are-getting-suckered-by-old-school-text-salting/5274434 logsource: category: email_gateway product: generic detection: selection_hidden_markers: raw_html|contains: - '