# Slack Unfurl Exfiltration Vector — Untrusted Fetch then Data-Bearing Link Send

- **Severity:** Medium
- **Signature ID:** `6f1c2d84-9a37-4e51-b0c2-7d5e83a41f96`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection), AML.T0025 (Exfiltration via Cyber Means)
- **OWASP:** LLM01 (Prompt Injection), LLM02 (Sensitive Information Disclosure)

## Summary

This rule looks for an AI agent that fetches content from an outside website and then, shortly after, sends a Slack message containing a crafted link to a non-Slack host. The pattern matches a known Slack link-preview (unfurl) exfiltration technique where sensitive data is smuggled out inside a URL that Slack automatically fetches to generate a preview.

## How the attack works

An AI agent or a tool it controls first retrieves content from a public external website. Within about 15 minutes, the same agent sends a message to a Slack channel, file, or webhook that contains a link engineered to carry data (for example, a URL with sensitive parameters) pointing at a host outside Slack. When Slack unfurls that link to build a preview, its own infrastructure fetches the URL and effectively transmits the embedded data to the attacker-controlled host. The rule only sees and flags the outbound Slack message with the crafted link — it does not and cannot observe Slack's own unfurl fetch, which happens on Slack's servers.

## Why it matters

An attacker who can inject instructions into an agent's workflow can use Slack's automatic link preview feature to leak internal data to an external server, using a legitimate business channel as the exit path. This is one narrow, detectable link in that chain, not proof that data actually left the network.

## What you can do

- Review any alert by checking whether the linked host matches the site the agent just fetched from, or whether the link contains credential-like or unusually long encoded parameters — these are stronger signs of exfiltration than a normal shared link.
- Turn off or restrict automatic link unfurling in Slack for bots and integrations that don't need it, especially for links to unfamiliar external domains.
- Require agents to use masked or descriptive link text rather than raw URLs when posting to Slack, so payload-bearing links are easier to spot.
- Restrict which external hosts an AI agent is allowed to fetch from and post links to, and log agent-initiated Slack posts for periodic manual review.

## Known benign look-alikes

- Agent researches a vendor page or documentation site and then legitimately shares a long presigned / tokenised link (S3, Google Drive, Notion, Figma, Grafana snapshot, CI artefact) into Slack. Mitigated by requiring the link to be masked with a label that does not name its own host, or to carry credential-shaped material, or to point at the very host the agent just fetched from.
- Release or alerting bots posting Slack mrkdwn links with build hashes or signed URLs. Mitigated by the same masked/closed-loop/secret-marker discriminator and by the 15-minute window tying the send to a preceding public fetch.
- Support workflows where the agent scrapes a customer page and then posts that same page's link back into Slack — this legitimately trips the closed-loop signal. Expect these; they are the main residual noise source and are why the action is report.
- URL shorteners and analytics redirectors whose paths look like encoded blobs.
- Multiple Slack sends about the same external host inside an hour are suppressed by a per-link-host cooldown, so a chatty thread yields one finding, not many.

## References

- https://owasp.org/www-project-top-10-for-large-language-model-applications/
- https://attack.mitre.org/techniques/T1567/
- https://atlas.mitre.org/techniques/AML.T0051

---
Source: https://www.netzilo.com/threats/slack-unfurl-exfil-chain