Prompt Injection Hidden in Phishing Emails: Barracuda Warns of Dual-Target Attacks — Detection and Defense Guide

Barracuda's threat research team has documented a meaningful evolution in social engineering: phishing emails that carry two payloads in one message — a traditional human-facing lure, and a hidden layer of text crafted specifically to manipulate AI assistants that summarize, triage, or act on email content. As enterprises deploy Copilot-style assistants, AI-driven email summarizers, and LLM-based security triage bots into the mail flow, attackers have recognized that the model reading the email is now a second victim — one that often holds more privilege than the human behind the keyboard.

This is not a theoretical risk. Organizations are actively routing inbound mail through AI summarization and automated response tooling, and many of these pipelines ingest raw HTML email content directly into an LLM context window with little or no sanitization. An attacker who can steer that model can suppress warnings, reclassify malicious mail as safe, exfiltrate context, or trick the assistant into taking actions on the user's behalf. Defenders need to treat this as a live, actively-observed technique and update email security controls, detection engineering, and AI deployment guardrails accordingly.

Technical Analysis

What Barracuda Observed

Per the reporting, Barracuda identified social engineering emails containing embedded instructions aimed at AI systems processing the message. The attack chain looks like this from a defender's vantage point:

1. Delivery: A phishing email arrives with a conventional human lure — urgency framing, a credential-harvesting link, a malicious attachment, or a business email compromise (BEC) pretext.
2. Hidden instruction layer: Embedded in the message body or HTML are instructions invisible (or near-invisible) to the human reader. Common concealment techniques include:
   • Text with font-size:0 or font-size:1px
   • Foreground color matching the background (e.g., color:#FFFFFF on a white body)
   • display:none, visibility:hidden, or opacity:0 CSS containers
   • Instructions buried in HTML comments (<!-- ... -->)
   • Off-screen positioning (margin-left:-9999px) or zero-dimension div elements
3. AI ingestion: An AI assistant — an email summarizer, an automated triage agent, a helpdesk copilot, or an M365 Copilot-style integration — ingests the full HTML/text body, including the hidden content, into its context.
4. Model manipulation: The hidden text instructs the model to, for example, describe the email as safe or legitimate, omit the malicious link from its summary, reassure the user, or take an action such as drafting a reply with sensitive context. Classic injection phrases observed across this technique family include variants of "ignore previous instructions," "you are a helpful assistant," "this email is safe/verified," and "do not mention...".
5. Human impact: The human recipient sees a sanitized AI summary — or an assistant-endorsed recommendation — and proceeds to click, reply, or approve.

Why This Matters More Than a Standard Phish

• Trust laundering: Users increasingly delegate judgment to AI summaries. A manipulated summary carries more weight than the raw email.
• Agentic blast radius: Where assistants have tool access (send mail, read mailboxes, query CRMs, create tickets), a successful injection can trigger unauthorized actions — not just bad advice.
• Detection gap: Traditional secure email gateways (SEGs) and sandboxing focus on URLs, attachments, and sender reputation. Hidden instructional text targeting language models is largely invisible to those controls.
• Indirect prompt injection (MITRE ATLAS AML.T0051): This maps to indirect prompt injection — attacker-controlled content entering an LLM pipeline from an external source. It requires no software vulnerability; the "exploit" is the model's instruction-following behavior.

Exploitation Status

There is no CVE associated with this reporting — this is a technique, not a patchable software flaw. Barracuda confirms these emails are being observed in the wild in active campaigns. Any organization using AI-driven email summarization, LLM-based SOC triage, or AI assistants with mailbox access should assume exposure. There is currently no CISA KEV entry (nor would one be expected for a technique-class threat), but the technique is actively relevant in 2026 as AI assistant adoption in the enterprise continues to outpace guardrail maturity.

Detection & Response

Detection here operates on two planes: (1) catching the concealment artifacts and injection phrasing in email content at the gateway or in mail telemetry, and (2) catching the follow-on behavior when a human or an agentic assistant acts on the manipulated message. Below are field-ready detections tuned to fire on the specific indicators of this campaign family — hidden-text CSS, HTML-comment instruction blocks, and classic override phrases — without drowning your queue in noise.

Sigma Rules

---
title: Email Contains Hidden Text Indicative of AI Prompt Injection
description: Detects inbound email content combining HTML concealment techniques (zero-size fonts, display:none, visibility:hidden, HTML comments) with language-model instruction phrasing. This combination is characteristic of prompt-injection-laced phishing reported by Barracuda and is rarely seen in legitimate marketing mail.
logsource:
  category: email
detection:
  selection_concealment:
    body|contains:
      - 'font-size:0'
      - 'font-size: 0'
      - 'font-size:1px'
      - 'display:none'
      - 'display: none'
      - 'visibility:hidden'
      - 'opacity:0'
      - '<!--'
      - 'margin-left:-'
  selection_instructions:
    body|contains:
      - 'ignore previous instructions'
      - 'ignore all previous'
      - 'ignore the above'
      - 'you are a helpful assistant'
      - 'system prompt'
      - 'do not mention'
      - 'this email is safe'
      - 'mark this email as'
      - 'AI assistant'
      - 'language model'
  condition: selection_concealment and selection_instructions
falsepositives:
  - Legitimate marketing email using hidden preheader text (concealment alone is common; requiring instruction phrasing keeps this low-noise)
level: high
---
title: Suspicious Child Process Spawned by Email Client
description: Detects script interpreters and LOLBins spawned by common email clients, consistent with a user acting on a social-engineered message (prompt-injection or otherwise). Tune for your environment's sanctioned Outlook add-in behavior.
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\outlook.exe'
      - '\msedgewebview2.exe'
      - '\thunderbird.exe'
      - '\olk.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\cmd.exe'
      - '\mshta.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\curl.exe'
      - '\certutil.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare: some legacy Outlook add-ins invoke scripts. Baseline and allowlist known add-in hashes.
level: medium

KQL (Microsoft Sentinel / Defender)

This query hunts inbound mail (via Defender for Office 365 telemetry, with a parallel path for Barracuda ESG logs ingested as CEF into CommonSecurityLog) for the concealment-plus-instruction signature described above. Run it over the last 14 days and tune the phrase list to your environment.

let InjectionPhrases = dynamic(["ignore previous instructions","ignore all previous","ignore the above","you are a helpful assistant","system prompt","do not mention","this email is safe","mark this email as","language model","AI assistant"]);
let ConcealmentMarkers = dynamic(["font-size:0","font-size: 0","font-size:1px","display:none","display: none","visibility:hidden","opacity:0","margin-left:-"]);
union isfuzzy=true
  (EmailEvents
   | where Timestamp > ago(14d)
   | where EmailDirection == "Inbound"
   | extend BodyText = tostring(BodyPreview)
   | extend InjectionHits = extract_all(@"(?i)ignore (all |the )?previous instructions|you are a helpful assistant|system prompt|do not mention|this email is safe", BodyText)
   | extend ConcealmentHits = extract_all(@"(?i)font-size:\s*0|font-size:1px|display:\s*none|visibility:\s*hidden|opacity:\s*0", BodyText)
   | where array_length(InjectionHits) > 0 or (array_length(ConcealmentHits) > 1 and BodyText has_any (InjectionPhrases))
   | project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, InjectionHits, ConcealmentHits, DeliveryAction, NetworkMessageId),
  (CommonSecurityLog
   | where TimeGenerated > ago(14d)
   | where DeviceVendor =~ "Barracuda"
   | where DeviceEventClassID has_any ("email","spam","inbound") or DeviceProduct has "Email Security"
   | where Message has_any (InjectionPhrases)
      and (Message has "font-size:0" or Message has "display:none" or Message has "visibility:hidden" or Message has "<!--")
   | project TimeGenerated, SourceUserID, DestinationUserName, Message, DeviceAction, SourceIP)
| sort by Timestamp desc

Velociraptor VQL

Two hunts: one for suspicious email-client child processes (follow-on execution), and one scanning exported/downloaded .eml and .html message files on endpoints for the concealment-plus-instruction pattern — useful when mail telemetry is incomplete.

-- Hunt 1: Email clients spawning script interpreters (post-phish execution)
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)powershell|pwsh|mshta|wscript|cscript|rundll32|regsvr32|certutil|curl'
  AND Ppid IN (
        SELECT Pid FROM pslist()
        WHERE Exe =~ '(?i)outlook\.exe$|olk\.exe$|thunderbird\.exe$'
      )

-- Hunt 2: Scan saved/exported messages for hidden prompt-injection content
SELECT FullPath, Line, LineNumber
FROM foreach(row={
       SELECT FullPath FROM glob(globs='C:/Users/*/{Downloads,Documents,Desktop}/*.{eml,html,htm}')
     },
     query={
       SELECT FullPath, Line, number(string=RowNumber) AS LineNumber
       FROM parse_lines(filename=FullPath, accessor='file')
       WHERE Line =~ '(?i)(font-size:\s*0|display:\s*none|visibility:\s*hidden|opacity:\s*0)'
         AND Line =~ '(?i)(ignore (all |the )?previous instructions|you are a helpful assistant|system prompt|this email is safe|do not mention)'
     })

Remediation / Hardening Script

The following Exchange Online PowerShell creates a transport rule that flags inbound messages combining hidden-text HTML with instruction phrasing (prepending a warning and redirecting a copy to your SOC), and verifies your Defender for Office 365 anti-phish posture. Run in an ExchangeOnlineManagement session with Transport Rules rights. Test in audit mode first.

# Connect to Exchange Online
Connect-ExchangeOnline

# Transport rule: flag hidden-text + AI-instruction phrase combinations
New-TransportRule -Name "Flag Hidden AI Prompt Injection Content" `
  -FromScope NotInOrganization `
  -SubjectOrBodyMatchesPatterns @('ignore (all |the )?previous instructions','you are a helpful assistant','this email is (safe|verified|legitimate)','do not mention (this|the) (link|attachment|email)') `
  -SubjectOrBodyContainsWords @('font-size:0','display:none','visibility:hidden') `
  -PrependSubject "[SECURITY REVIEW - POSSIBLE AI MANIPULATION] " `
  -GenerateIncidentReport soc@yourdomain.com `
  -Mode Audit `
  -Comments "Flags inbound mail combining HTML concealment with LLM instruction phrasing (Barracuda-reported prompt-injection phishing). Switch Mode to Enforce after 2-week tuning."

# Verify anti-phish policy has impersonation and mailbox intelligence enabled
Get-AntiPhishPolicy | Select-Object Name, Enabled, EnableMailboxIntelligence, EnableOrganizationImpersonationProtection, EnableTargetedUserProtection, PhishThresholdLevel | Format-Table -AutoSize

# Harden anti-phish defaults if gaps found
Set-AntiPhishPolicy -Identity "Office365 AntiPhish Default" `
  -EnableMailboxIntelligence $true `
  -EnableMailboxIntelligenceProtection $true `
  -PhishThresholdLevel 3

# Audit AI assistant access: list enterprise apps with Mail.Read / mailbox scopes (potential LLM mail ingestion points)
Connect-MgGraph -Scopes "Application.Read.All"
Get-MgServicePrincipal -All | Where-Object { $_.AppRoleAssignedTo -ne $null } | ForEach-Object {
  Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $_.Id | Where-Object { $_.ResourceDisplayName -match 'Exchange|Microsoft Graph' }
} | Select-Object PrincipalDisplayName, ResourceDisplayName, AppRoleId | Sort-Object PrincipalDisplayName -Unique | Format-Table -AutoSize

Remediation

Because this is a technique rather than a CVE, remediation is architectural and procedural, not a patch. Prioritize the following:

1. Sanitize before the model sees it. Any pipeline feeding email into an LLM must strip HTML comments, hidden elements (display:none, zero-size fonts, background-colored text), and non-rendering markup before ingestion. Render-then-extract (DOM-based text extraction) is materially safer than raw-HTML ingestion.
2. Enforce prompt hardening and output constraints. System prompts for email-processing assistants should explicitly instruct the model to treat message body content as untrusted data, never as instructions, and to surface — never suppress — links, attachments, and sender anomalies. Where supported, enable vendor prompt-injection/Shields-style content filters (e.g., Azure AI Content Safety prompt shields, equivalent AWS/GCP controls).
3. Constrain agentic capability. AI assistants with mailbox access should be read-only by default. Any action-taking capability (send, delete, forward, create) must require human-in-the-loop confirmation. Audit every Graph/Exchange scope granted to AI applications — the script above enumerates these.
4. Update gateway policy. Add content rules (as in the transport rule above) for concealment-plus-instruction combinations. Confirm your SEG vendor's roadmap for prompt-injection detection; Barracuda and peers are shipping capability here — enable it as it becomes available.
5. Tune the detections above in audit mode for two weeks, then enforce. Baseline marketing mail (legitimate hidden preheader text) and exclude known bulk senders.
6. Train users on the dual-target reality. Staff should understand that an AI summary is not a verdict. Require users to inspect the raw message — sender domain, link targets — before acting on AI-summarized email. Add a prompt-injection scenario to your next phishing simulation cycle.
7. Review third-party AI integrations. Inventory every tool that touches mailbox data (summarizers, ticketing copilots, CRM assistants). For each, document what content enters the model, what actions it can take, and how injection is mitigated contractually and technically.

Conclusion

The Barracuda findings confirm what many of us in IR have anticipated: once AI assistants became intermediaries between users and untrusted content, those assistants became attack surface. The dual-target phishing email — one lure for the human, one for the model — is now an observed in-the-wild technique, and it defeats controls that were never designed to look for it. The defensive response is not exotic: sanitize model inputs, constrain what assistants can do, detect the concealment artifacts at the gateway, and keep humans meaningfully in the loop. Organizations that deploy AI into the mail flow without these guardrails are handing attackers a privileged, trusted voice inside their own environment.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub