# Disguised Analytics Exfiltration

- **Severity:** High
- **Signature ID:** `7c3f9e2a-5b41-4d8e-9a6c-1f0b2d7e64c3`
- **MITRE ATLAS:** AML.T0057 (LLM Data Leakage)
- **OWASP:** LLM06 (Excessive Agency), ASI04 (Memory and Context Poisoning), ASI06 (Goal and Instruction Manipulation)

## Summary

An AI agent sends sensitive data — credentials, conversation history, or model context — to a web endpoint that looks like a normal analytics or telemetry service (paths like /collect, /ingest, /telemetry). The traffic is designed to blend in with routine monitoring calls, hiding the theft in plain sight.

## How the attack works

An agent process first reads something sensitive, such as a credential store, or writes a staging file. It then sends an HTTP request to a destination whose URL or hostname looks like an analytics or telemetry service. The request body, however, doesn't match what real telemetry looks like: it contains credential material, markers of conversation or model context, or a large opaque encoded blob (512 bytes or more). Credential material sent this way is flagged immediately, since credentials never belong in telemetry. Context or blob payloads are only flagged if they follow a matching sensitive read or file write from the same session within a 10-minute window, which cuts down on false alarms from legitimate tracing tools.

## Why it matters

An organization can lose credentials, conversation transcripts, or internal model context to an external party while the traffic looks like harmless monitoring data, making the theft harder to spot in normal log review.

## What you can do

- Restrict which hosts and paths agent processes are allowed to send outbound HTTP requests to, and review any analytics/telemetry-shaped endpoints that aren't your own observability stack.
- Never let logging, tracing, or telemetry configurations point at attacker-controlled or unreviewed external hosts; audit these settings periodically.
- Watch for outbound requests carrying credential markers or large encoded blobs, even when the destination looks like a normal analytics endpoint.
- If you run LLM observability tooling, keep trace collectors on trusted internal hosts and scope your sensitive-file monitoring path narrowly to reduce noise from legitimate tracing traffic.

## Known benign look-alikes

- LLM observability / tracing SDKs (self-hosted trace collectors, OTEL GenAI exporters) that legitimately POST prompts and completions to an ingestion endpoint. These carry context markers but are only reported when the same session also read a credential store or wrote a staging artifact inside the 10 minute window. Tune by narrowing SENSITIVE_PATH, not by allowlisting hosts.
- Crash / error reporters that attach a base64 minidump or gzipped breadcrumb blob to a /ingest or /report endpoint. Blob-only anchors always require a staging corroboration, which crash reporters normally do not produce.
- Product analytics with session replay, which can post large encoded DOM payloads to /collect. Same blob-tier corroboration requirement applies.
- CI/CD log shippers posting build logs to /logs or /ingest from an agent session that also touched .npmrc or .git-credentials during the same build.
- A developer deliberately exporting a conversation transcript to an internal metrics endpoint for evaluation work.

## References

- https://atlas.mitre.org/techniques/AML.T0057
- https://attack.mitre.org/techniques/T1567/
- https://attack.mitre.org/techniques/T1071/001/

---
Source: https://www.netzilo.com/threats/disguised-analytics-exfiltration