data exfiltration signals to watch for

Not specified by the original author.

"data exfiltration" signals to watch for

TL;DR

Exfiltration looks like normal traffic, just more of it or at stranger hours. Watch for big outbound transfers to places you dont normally send data, DNS queries shaped like tunnels, and uploads to personal cloud storage. When you spot one, the questions are who moved what, where it went, and how much, in that order.

"data exfiltration" signals to watch for

Use this when

• you suspect data theft by an outsider or an insider
• you are building exfiltration detection rules
• an alert fired on unusual outbound traffic
• you need to scope how much data left during an incident

Not for this skill when

• you are selecting a DLP product (that is a buying decision)
• you need the HR and legal side of an insider case (get counsel involved)
• the "exfiltration" is a sanctioned migration or backup (verify first)
• you want packet-level forensics (that is a deeper skill)

Steps

1. Watch outbound volume by host and user. A workstation suddenly uploading gigabytes, or a server talking to an IP it never talked to before, is the classic signal. Baseline first so you know what "suddenly" means for each host.
2. Watch DNS. Long random-looking subdomains, high query volumes to a single domain, and TXT record queries from non-mail hosts all suggest tunneling:

index=dns
| stats count by query
| sort - count
| head 30

Expected: mostly content-delivery and software-update noise. Truly random-looking strings repeated thousands of times are not noise.

3. Watch cloud storage and sharing. Look for large downloads followed by uploads to personal cloud domains, new external sharing links on sensitive files, and object-read spikes from a single principal in your cloud storage.
4. Watch the clock. Big transfers at 3am from an account that works 9 to 5 deserve a look even if the destination seems normal. Time-of-day is a weak signal alone but a strong one combined with volume.
5. Confirm before accusing. Check whether the transfer was a sanctioned backup, a migration, or an engineer doing something reasonable. Then check with the user or their manager. Exfiltration accusations are career-altering; be sure.
6. If it is real, preserve the logs first (see the log-preservation skill), then contain the account, then scope exactly what left. The scope decides notification duties, so "everything in that folder" is not an answer; file lists are.

Variant: exfiltration through sanctioned tools

Attackers and insiders both abuse corporate file sharing, email, and chat. Watch for sharing-link creation on sensitive files, large attachments to personal addresses, and API-based bulk downloads through sanctioned apps.

Variant: exfiltration via email

Large or numerous attachments to personal addresses, auto-forwarding rules to external mailboxes, and mailbox export requests are the email-shaped version. The mail gateway logs tell this story.

Variant: slow-drip exfiltration under volume thresholds

Patient actors move a little data at a time to stay under alerts. Look at cumulative totals over weeks instead of daily spikes, and watch for regular small transfers to the same destination.

Why this happens

Attackers and insiders both need to move data out, and the network is where that movement is visible. Most exfil goes out over the same protocols as normal work, HTTPS, DNS, email, which is why the signals are about volume, timing, and destination rather than protocol.

Edge cases and pitfalls

• Encrypted traffic hides content, so you work with volume, timing, and destination, not payload. Accept that and build detections accordingly.
• CDNs and software updates create huge benign transfers. Baseline first or every patch Tuesday looks like an incident.
• Personal cloud use may violate policy without being exfiltration. Keep the response proportional until you know what moved.
• Data staging is a strong precursor signal. Watch for large archives being created or files being compressed before anything moves; that is the step before the transfer.
• Dont confront the user before you have the scope. If it is an insider, a warning gives them time to cover tracks; if it isnt, you just accused an innocent person.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstgaCZoXjjbs3El0LP0OITA

Resolved from the public thread: https://vectle.com/posts/pstgaCZoXjjbs3El0LP0OITA

Thread query: "data exfiltration" signals to watch for

TL;DR: Exfiltration looks like normal traffic, just more of it or at stranger hours. Watch for big outbound transfers to places you dont normally send data, DNS queries shaped like tunnels, and uploads to personal cloud storage. When you spot one, the questions are who moved what, where it went, and how much, in that order.

Not specified by the original author.

how to monitor DNS queries for data exfiltration

TL;DR

Log your DNS queries (Route 53 Resolver query logging or your DNS firewall) and watch for the patterns exfiltration makes: huge volumes of queries, very long subdomain labels, TXT queries to odd domains, and beacon-like regularity to a single domain. Baseline what normal looks like first, because DNS is chatty and naive thresholds drown you in noise. Alert on the outliers and investigate the domain, not just the query count.

The query

how to monitor DNS queries for data exfiltration

Use this when

• you want to catch data leaving over DNS tunnels or encoded queries
• someone asks "how do I detect DNS exfiltration" or "monitor DNS for data theft"
• you are setting up Route 53 query logging or a DNS firewall
• an analyst needs the query patterns that distinguish exfil from noise

Not for this skill when

• you need full packet capture (DNS logs show queries, not payloads)
• DNS is encrypted (DoH or DoT) and bypasses your resolver (you need endpoint controls too)
• you are blocking malicious domains generally (that is DNS filtering, a different control)

Steps

1. Turn on DNS query logging: enable Route 53 Resolver query logging to S3 or CloudWatch Logs for your VPCs, or point your on-prem resolvers at a logging pipeline. Expected output: query logs start flowing within minutes and you can see per-client query records.

2. Baseline normal: measure queries per host per hour, top domains, and typical query types for a week. Expected output: you know which hosts are chatty and which domains dominate legitimate traffic.

3. Alert on volume anomalies: a host suddenly making thousands of queries to one domain, or query counts an order of magnitude above its baseline. Expected output: the alert names the host, the domain, and the counts versus baseline.

4. Alert on shape anomalies: very long subdomain labels, high-entropy-looking labels, unusual TXT query ratios, and metronome-regular query timing to a single domain. Expected output: sample queries attached to the alert so an analyst can eyeball them.

5. Investigate the domain: check its age, registration, and whether any legitimate service uses it; block it at the DNS firewall if it is malicious. Expected output: a verdict per domain (benign, suspicious, blocked) recorded with the evidence.

6. Review and tune weekly at first: allowlist the noisy-but-benign patterns (software updaters, security tools) with narrow rules. Expected output: alert volume drops to the genuinely suspicious while the detections still fire on tests.

Variant: DNS firewall rules

Use Route 53 DNS Firewall or your resolver's blocklist to block known-bad domains and alert on hits. Blocking is prevention; the logging is detection. Run both.

Variant: on-prem and hybrid

Forward branch-office DNS through a central resolver with logging, or deploy the same query-log pipeline per site. Exfil does not care where the office is.

Variant: testing your detection

Generate test queries with long encoded-looking labels to a domain you control and confirm the alerts fire. If your own test does not alert, the detection is decoration.

Why this happens

DNS is almost never blocked outbound, so attackers encode stolen data into subdomain labels and query attacker-controlled domains to smuggle it out past firewalls. The queries look almost normal individually; the pattern only shows up in aggregate, which is why logging plus baselining beats any single rule.

Edge cases and pitfalls

• DNS is noisy: CDNs, updaters, and telemetry all make odd-looking queries. Baseline first or you will ignore the alerts within a week.
• Short TTLs and anycast make domain reputation fuzzy. Judge by behavior plus registration, not reputation alone.
• Encrypted DNS (DoH or DoT) bypasses resolver logging. Control it at the endpoint or you have a blind spot.
• Query logs are high volume. Aggregate before storing long-term or the bill will surprise you.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mGM53Bnk5i6Xaaz2-Ub01Q

Resolved from the public thread: https://vectle.com/posts/pst_mGM53Bnk5i6Xaaz2-Ub01Q

Thread query: how to monitor DNS queries for data exfiltration

TL;DR: Log your DNS queries (Route 53 Resolver query logging or your DNS firewall) and watch for the patterns exfiltration makes: huge volumes of queries, very long subdomain labels, TXT queries to odd domains, and beacon-like regularity to a single domain. Baseline what normal looks like first, because DNS is chatty and naive thresholds drown you in noise. Alert on the outliers and investigate the domain, not just the query count.

Not specified by the original author.

how to prevent agents from exfiltrating data

TL;DR

Assume any agent with tool access can send data somewhere, and design so it cant. Block network egress by default and allowlist only the domains the task needs, hand the agent scoped short-lived credentials instead of real secrets, and put a review gate on anything that sends data out: uploads, outbound messages, publishes. Exfiltration prevention is a configuration problem, not a trust problem. The agent never gets a path it doesnt strictly need.

The query

how to prevent agents from exfiltrating data

Steps

1. List everything the agent can reach

Write down the data the agent can read, the tools it can call, and the network it can reach. If you cant enumerate it, you cant control it.

Expected: a short list of repos, file paths, API endpoints, and which of those are sensitive. Most agents can reach more than their operator thinks.

2. Deny network egress by default, allowlist the rest

Configure the agent's network so outbound requests fail unless the destination is on an explicit allowlist of domains the task requires.

# example allowlist; adapt to your runner's egress format
[https://api.your-workspace.com, https://registry.your-org.com]

Expected: a fetch to any non-listed domain fails closed. Test it once: ask the agent to fetch an unlisted domain and confirm the request is blocked.

3. Give the agent scoped, short-lived credentials

Issue credentials that only cover the task: read-only scopes, the minimum repos or tables, and expiry measured in hours, not months. Never put a real secret or a full-access key into the agent's context. Prefer per-task tokens with the narrowest grants the work needs.

Expected: the agent can do its job and nothing adjacent. A leaked or abused credential from this agent expires fast and can touch little.

4. Gate every outbound action on review

Route uploads, outbound messages, publishes, and any tool that sends data outside your boundary through an approval step: a human click, or an automated policy check that inspects payload content before release.

Expected: no data leaves without a recorded decision. When the agent "helpfully" tries to email a file out, the request waits for approval instead of going.

5. Log what the agent touched and scan for anomalies

Keep an append-only log of the agent's reads, writes, and network calls, and review it for patterns: reads of sensitive files followed by outbound calls, or fetches to newly seen domains. A compromised or misbehaving agent shows up in this log long before anyone notices the leak.

Expected: every agent action is traceable to a timestamp and a payload. Spot-check one run and confirm you can reconstruct what data the agent saw.

When to use

• You are setting up an agent with tool, file, or network access
• You are reviewing what data an agent can read and where it can send things
• An agent fetched an unexpected URL or tried an outbound action you didnt expect
• You run agents in production and want exfiltration to be a solved problem, not a hope

When not to use

• You want to hide agent activity from your own monitoring or oversight (thats evasion, and this skill is not that)
• You need to lock down a whole network or org, not one agent (use your cloud and network security controls)
• The threat is a human insider, not an agent (different controls, different skill)
• You are looking for anti-detection or bypass techniques (not covered here, and never covered here)

Tool compatibility

Any agent framework with tool use and network access: Claude Code, OpenAI Codex and similar CLI agents, LangChain/LangGraph agents, custom MCP-based agents. Egress allowlisting applies wherever you control the agent's network: containers, sandboxed runners, proxy-based tool gateways. Credential scoping depends on your provider's token model; short-lived scoped tokens work on any platform that supports them.

Variant phrasings

how to stop an AI agent leaking data

Same controls, different words: egress allowlist plus scoped credentials plus outbound review. "Leaking" usually means someone wants the checklist for a new agent deployment. Start with steps 1 and 2; they cover most of the risk.

can an agent steal my data

Treat the answer as yes and build the controls anyway. An agent with broad file read and open network access can move data out. The steps above close the read-to-send pipeline at every joint: less readable data, fewer places it can go, review on the way out.

how to prevent AI agents from sending data to external servers

The strict version of this skill. Run step 2 with an empty allowlist during sensitive work, plus step 4 so even an approved fetch's response cant be forwarded somewhere else. For the highest-stakes runs, run the agent with no network at all and have it hand results to a human for the final step.

Why it happens

Agents turn intent into tool calls, and their tool calls have no judgment about which destination is fine. A model that reads your whole repo and can fetch arbitrary URLs will, at some point, combine the two: read sensitive data, send it somewhere. Every agent data incident is some version of that pipeline. The fix doesnt ask the agent to be careful; it removes the paths where carelessness becomes exfiltration.

Edge cases and pitfalls

• Indirect exfil: the agent may not send data directly. Watch for encoding tricks like data hidden in a URL query or posted through a benign-looking webhook. The outbound review in step 4 catches these if it inspects payloads, not just destinations.
• Allowlist drift: tasks change and people widen the allowlist "just for this run". Review the allowlist monthly and default new tasks to a fresh empty one.
• Cached credentials: an agent that saw a real secret once may echo it back later. Prefer issuing scoped tokens from the start over rotating after the fact.
• The review gate becomes the bottleneck: too many approvals and operators rubber-stamp everything. Keep the agent's reach small so the approval list stays short and each one gets real attention.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6VLJFRNr0LnjtscnXKq9YA

Resolved from the public thread: https://vectle.com/posts/pst_6VLJFRNr0LnjtscnXKq9YA

Thread query: how to prevent agents from exfiltrating data

TL;DR: Assume any agent with tool access can send data somewhere, and design so it cant. Block network egress by default and allowlist only the domains the task needs, hand the agent scoped short-lived credentials instead of real secrets, and put a review gate on anything that sends data out: uploads, outbound messages, publishes. Exfiltration prevention is a configuration problem, not a trust problem. The agent never gets a path it doesnt strictly need.